delta/python-packages/sqlalchemy.git/test/dialect/mssql, branch pr/239

- add missing backend directives for SQL server

2016-02-08T19:20:12+00:00

- there was a DATEPART test after all, fix format

2016-01-14T22:50:03+00:00

- changelog for pr bitbucket:70, fixes #3624

2016-01-12T14:53:09+00:00

- A descriptive ValueError is now raised in the event that SQL server

2015-11-30T17:19:26+00:00

returns an invalid date or time format from a DATE or TIME
column, rather than failing with a NoneType error.  Pull request
courtesy Ed Avis.
pullreq github:206

- extend pullreq github:213 to also include DATETIMEOFFSET and TIME,

2015-11-14T17:38:45+00:00

which also accept zero precision
- extend test case here to include a backend-agnostic suite
- changelog for MSSQL date fix

Pass precision value to mssql.DATETIME2 when it is 0

2015-11-13T19:51:05+00:00

The simple check on the precision results in DATETIME2(0) generating a
DATETIME2 column, with default precision, which is 7.

- The ``legacy_schema_aliasing`` flag, introduced in version 1.0.5

2015-09-19T22:06:23+00:00

as part of :ticket:`3424` to allow disabling of the MSSQL dialect's
attempts to create aliases for schema-qualified tables, now defaults
to False; the old behavior is now disabled unless explicitly turned on.
fixes #3434

- fix the postgresql_jsonb requirement to include the 9.4 requirement

2015-08-18T17:30:21+00:00

- new test for json col['x']['y']['z'] seems to fail pre PG 9.4,
fails on comparisons for non-compatible data instead of not matching
- no need to call SpecPredicate(db) directly in exclusion functions,
by using Predicate.as_predicate() the spec strings can have version
comparisons

- Fixed issue where the SQL Server dialect would reflect a string-

2015-07-30T14:34:36+00:00

or other variable-length column type with unbounded length
by assigning the token ``"max"`` to the
length attribute of the string.   While using the ``"max"`` token
explicitly is supported by the SQL Server dialect, it isn't part
of the normal contract of the base string types, and instead the
length should just be left as None.   The dialect now assigns the
length to None on reflection of the type so that the type behaves
normally in other contexts.
fixes #3504

- Fixed issue when using :class:`.VARBINARY` type in conjunction with

2015-06-22T19:24:41+00:00

an INSERT of NULL + pyodbc; pyodbc requires a special
object be passed in order to persist NULL.  As the :class:`.VARBINARY`
type is now usually the default for :class:`.LargeBinary` due to
:ticket:`3039`, this issue is partially a regression in 1.0.
The pymssql driver appears to be unaffected.
fixes #3464