Scripts produced by ApexSQL Diff, which runs fine in SQL Server Management Studio, fail when run from a TFDScript. I am trying to figure out if it is options related, or if it is an implementation problem.
Problem 1: Transaction handing causes an error:
Exception class EMSSQLNativeException with message ‘[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL Server]A transaction that was started in a MARS batch is still active at the end of the batch. The transaction is rolled back.’.
Problem 2: If I remove the begin tran at line 38/39 and reduce the script to only contain the create table part – it still fails silently. The spool output shows no errors, nor does any errors show in the FireDAC Monitor. And yet – no table is created.
I also suspect that multiline /* block comments */ confuse the script analyzer.
MICROSOFT SQL SERVER CONNECTIVITY FEATURE PACK COMPONENTS
Microsoft® SQL Server® 2012 Native Client
Microsoft SQL Server Native Client (SQL Server Native Client) is a single dynamic-link library (DLL) containing both the SQL OLE DB provider and SQL ODBC driver. It contains run-time support for applications using native-code APIs (ODBC, OLE DB and ADO) to connect to Microsoft SQL Server 2005, 2008, 2008 R2, and SQL Server 2012. SQL Server Native Client should be used to create new applications or enhance existing applications that need to take advantage of new SQL Server 2012 features. This redistributable installer for SQL Server Native Client installs the client components needed during run time to take advantage of new SQL Server code name ‘Denali’ features, and optionally installs the header files needed to develop an application that uses the SQL Server Native Client API.
Yet another tidbit. Default stored proc parameter sizing.
The old parameter passing to the stored procedures is done with array of const and variants. No issues with that, until my xml logging feature had the mother of all stack traces, and exceeded 9k bytes in total xml size, upon which the assignment of TFDParam.Value complained that TFDParam.Size was 8002 bytes, and the size of the string was bigger than that.
I recently discovered that some of the few queries that we have that return a large rowset, would max out at 50 rows.
It turns out that TFDQuery.FetchOptions.Mode defaults to fmOnDemand, which means that the query first returns a default of 50 rows, and then fetches 50 more as you MoveNext past the 50 first. Other options are fmAll, fmExactRecsMax, fmManual.
Since we still are in the “make it work” and not in the “make it fast” stage, I switched to using fmAll.
Interestingly, RowCount by default also returns 50 even if the query actually matches more rows. and there is a TFDQuery.FetchOptions.RecordCountMode setting that can be modified, as well: cmFetched, cmVisible, cmAll.
This differs from ADO TQuery, which will retrieve all rows and the full record count by default.
TFDDataSet has the same settings, and there are numerous other tweakable parameters that I need to explore for both of these components..