SQL Server FDO provider crashes when querying a table with an 'image' column

[jng]

Attached is DDL for a SQL Server table with an image column

If you do a basic ISelect query against this table the client application (be that MapGuide, FDO Toolbox, etc) will crash.

This column does show up in any class definitions requested as a FDO BLOB property

[jng]

DDL for example table

[jng]

Patch GdbiQueryResult to ignore RDBI_BLOB and ensure consistent new/delete

[jng]

The SQL Server image column resolves to type RDBI_BLOB, which causes causes GdbiQueryResult to crash in the destructor due to inconsistent ordering of new/delete operations, which happened to slip under the radar with other RDBI column types, but the inconsistency was exposed with RDBI_BLOB where the destructor will try to delete[] colInfo->value as wchar_t[] (that it was never assigned to) under the current logic

Attached is a patch that will ensure consistent new/delete.

However this still does not make queries that involve SQL Server image columns work as the size reported by SQL Server for RDBI_BLOB is 2^31, which will generally fail allocation with std::bad_alloc under the current allocation code paths in define_exec

So this patch will also skip over RDBI_BLOB in define_exec and ~GdbiQueryResult and no-ops GdbiQueryResult::GetBinaryValue if the column type is RDBI_BLOB. Not desirable, but still a net gain over what currently happens.

[jng]

Actually, since image is effectively a deprecated column type and slated for removal in a future version of SQL Server (​https://docs.microsoft.com/en-us/sql/t-sql/data-types/ntext-text-and-image-transact-sql) and since we can't get the FDO provider working with image columns anyways, a better approach to this would be to simply make sure image columns are properly skipped over.