TBoldSQLDataBaseConfig.UseBatchQueries concatenates the write statements of one UpdateDatabase into a single command (#80). Whether a server accepts several statements in one command - and parameters spread across them - is an engine property that the data-access layer does not abstract: SQL Server (TDS) does, SQLite via FireDAC does (verified), Oracle only inside a BEGIN … END; block (the config has the wrapper, unverified), Interbase/Firebird DSQL executes one statement per call, PostgreSQL's extended protocol allows one statement per parameterized command, MySQL needs a client flag. Only two engine branches in InitializeDbEngineSettings were ever written with batching in mind (dbeSQLServer tuning, dbeOracle wrapper).
Today nothing stops a user from enabling the flag on Firebird or PostgreSQL; the result is a save that fails at the server - or worse, partially applies - with an error that points at SQL syntax rather than at the setting.
Fix
TBoldSQLDataBaseConfig.BatchQueriesVerified: Engine in [dbeSQLServer, dbeGenericANSISQL92] - the engines the batch tests have run on (SQL Server, and SQLite which the test suite configures as generic ANSI SQL92).TBoldBatchDataSetWrapper.StartSQLBatch: when UseBatchQueries is on for another engine, raise EBold naming the engine and the verified ones, before any statement is accumulated. The save fails at once with a message about the setting instead of a server error mid-batch.- The
UseBatchQueries property comment lists the verified engines.
Verifying batching on another engine means running Test.BoldBatchQueries / Test.PersistenceScenarios* against it and adding it to the set.
Files changed
Source/PMapper/SQL/BoldSQLDatabaseConfig.pasSource/Persistence/DB/BoldDBInterfaces.pasSource/ObjectSpace/Core/BoldCoreConsts.pas (message)UnitTest/Code/Persistence/Test.BoldBatchQueries.pas
Testing
TBoldSQLDataBaseConfig.UseBatchQueriesconcatenates the write statements of oneUpdateDatabaseinto a single command (#80). Whether a server accepts several statements in one command - and parameters spread across them - is an engine property that the data-access layer does not abstract: SQL Server (TDS) does, SQLite via FireDAC does (verified), Oracle only inside aBEGIN … END;block (the config has the wrapper, unverified), Interbase/Firebird DSQL executes one statement per call, PostgreSQL's extended protocol allows one statement per parameterized command, MySQL needs a client flag. Only two engine branches inInitializeDbEngineSettingswere ever written with batching in mind (dbeSQLServertuning,dbeOraclewrapper).Today nothing stops a user from enabling the flag on Firebird or PostgreSQL; the result is a save that fails at the server - or worse, partially applies - with an error that points at SQL syntax rather than at the setting.
Fix
TBoldSQLDataBaseConfig.BatchQueriesVerified:Engine in [dbeSQLServer, dbeGenericANSISQL92]- the engines the batch tests have run on (SQL Server, and SQLite which the test suite configures as generic ANSI SQL92).TBoldBatchDataSetWrapper.StartSQLBatch: whenUseBatchQueriesis on for another engine, raiseEBoldnaming the engine and the verified ones, before any statement is accumulated. The save fails at once with a message about the setting instead of a server error mid-batch.UseBatchQueriesproperty comment lists the verified engines.Verifying batching on another engine means running
Test.BoldBatchQueries/Test.PersistenceScenarios*against it and adding it to the set.Files changed
Source/PMapper/SQL/BoldSQLDatabaseConfig.pasSource/Persistence/DB/BoldDBInterfaces.pasSource/ObjectSpace/Core/BoldCoreConsts.pas(message)UnitTest/Code/Persistence/Test.BoldBatchQueries.pasTesting
TestUnverifiedEngineIsRejected-Engine := dbePostgreson the live config withUseBatchQuerieson, a save must raise a message namingUseBatchQueriesand the engine; with the engine set back the same objects save normallyTest.PersistenceScenariosUniDAC5/5 underDebugUniDACon SQL Server (verified engine, guard silent)