Uploaded image for project: 'Doctrine DBAL'
  1. Doctrine DBAL
  2. DBAL-475

[GH-293] Add SAP SQL Anywhere database vendor


    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: None
    • Security Level: All
    • Labels:


      This issue is created automatically through a Github pull request on behalf of deeky666:

      Url: https://github.com/doctrine/dbal/pull/293


      This PR adds the driver and DBAL for SAP SQL Anywhere databases. It distinguishes between versions 10 and below (base <code>SQLAnywherePlatform</code>), 11 (<code>SQLAnywhere11Platform</code>) and 12 (<code>SQLAnywherer12Platform</code>), similar to Microsoft SQL Server.
      Most of the functional tests pass but there are some exceptions:

      • <code>DataAccessTest::testFetchAllWithTypes</code>
        Failed asserting that two strings are equal.
          • Expected
            +++ Actual
            @@ @@
            -'2010-01-01 10:10:10'
            +'2010-01-01 10:10:10.000'
            The test is not aware of the datetime format string of the platform, which differs in SQL Anywhere. Therefore it fails. In SQL Anywhere a datetime is stored with second fractions by default.
            IMO I have two options here. Changing the default timestamp format for data output in the driver on every connection so that it fits <code>Y-m-d H:i:s</code> and changing the date format strings in the platforms or modifying the test to be aware of the platform specific datetime format.
      • <code>MasterSlaveConnectionTest::testKeepSlaveBeginTransactionStaysOnMaster</code>
        The test simply hangs up here and I don't exactly know why. When I change the value for insert in line 95 to some other value than 30 it perfectly works. Any help would be appreciated here.
      • <code>ModifyLimitQueryTest::testModifyLimitQueryGroupBy</code>
        Failed asserting that two arrays are equal.
          • Expected
            +++ Actual
            @@ @@
            Array (
        • 0 => 1
        • 1 => 2
          ++ 0 => 2
          ++ 1 => 1
          The test does not tell the SELECT statement to order the result, thus the result is not deterministic and returns the results in wrong order.
          IMO the test should be fixed so that the result is ordered correctly. Then the test will pass for SQL Anywhere.
      • <code>TemporaryTableTest</code>
        <pre>Exception: [Doctrine\DBAL\DBALException] An exception occurred while executing 'CREATE GLOBAL TEMPORARY TABLE temporary (id INT NOT NULL)':
        SQLSTATE [42W04] [-131] Syntaxfehler bei 'temporary' in Zeile 1
        With queries:
        SQL: 'DROP TABLE temporary' Params:
        SQL: 'CREATE GLOBAL TEMPORARY TABLE temporary (id INT NOT NULL)' Params:
        SQL: 'DROP TABLE nontemporary' Params:</pre>
        The tests use the unquoted keyword "temporary" reserved by SQL Anywhere for the temporary table name to create.
        I cannot quote the name of the temporary table in the platform as the method <code>getTemporaryTableName</code> expects a string and not an instance of <code>Doctrine\DBAL\Schema\Table</code> as parameter.
        Either the tests should use a non reserved keyword as temporary table name or the temporary table name has to be quoted in the platform (but I don't know exactly how).
      • <code>TemporaryTableTest::testDropTemporaryTableNotAutoCommitTransaction</code>
        <pre>In an event of an error this result has one row, because of an implicit commit.
        Failed asserting that two arrays are equal.
          • Expected
            +++ Actual
            @@ @@
            Array (
            ++ 0 => Array (...)
            The test fails because of an implicit commit during the transaction (drop temporary table) which inserts the first value. I couldn't find a solution for this problem. Seems to be the same problem as reported in DDC-1337(http://www.doctrine-project.org/jira/browse/DDC-1337).
      • <code>WriteTest::testLastInsertIdNoSequenceGiven</code>
        <pre>Failed asserting that 14 is false.</pre>
        I don't exactly know why the test expects the lastInsertId to be false here. Using the same connection for 14 inserts into a newly created autoincrement table should result in lastInsertId = 14 IMO. Is this a bug in the test? How do other vendors behave here?

      I hope this addition is appreciated and any feedback/help on the above issues would be welcomed.



          • Assignee:
            beberlei Benjamin Eberlei
            beberlei Benjamin Eberlei
          • Votes:
            0 Vote for this issue
            2 Start watching this issue


            • Created: