|
Compatibility with Previous Versions |
|
|
|
Compatibility with Previous Versions |
|
We always try to keep SDAC compatible with previous versions, but sometimes we have to change the behaviour of SDAC in order to enhance its functionality, or avoid bugs. This topic describes such changes, and how to revert the old SDAC behaviour. We strongly recommend not to turn on the old behaviour of SDAC. Use options described below only if changes applied to SDAC crashed your existent application.
Values of the options described below should be assigned in the initialization section of one of the units in your project.
The BaseSQL property is similar to the SQL property, but it does not store changes made by AddWhere, DeleteWhere, and SetOrderBy methods. After assigning an SQL text and modifying it by one of these methods, all subsequent changes of the SQL property will not be reflected in the BaseSQL property. This behavior was changed in SDAC 3.55.2.22. To restore old behavior, set the BaseSQLOldBehavior variable to True.
If the manually assigned RefreshSQL property contains only "WHERE" clause, SDAC uses the value of the BaseSQL property to complete the refresh SQL statement. In this situation all modifications applied to the SELECT query by functions AddWhere, DeleteWhere are not taken into account. This behavior was changed in SDAC 4.00.0.4. To restore the old behavior, set the BaseSQLOldBehavior variable to True.
Starting with SDAC 4.20.0.12, the DataSetChange event is sent after the dataset gets open. It was necessary to fix a problem with disappeared vertical scrollbar in some types of DB-aware grids. This problem appears only under Windows XP when visual styles are enabled.
To disable sending this event, change the value of this variable to False.
Starting with SDAC 4.20.0.13, if the OnUpdateRecord event handler sets the UpdateAction parameter to uaFail, an exception is raised. The default value of UpdateAction is uaFail. So, the exception will be raised when the value of this parameter is left unchanged.
To restore the old behaviour, set DoNotRaiseExcetionOnUaFail to True.
In SDAC 4.00.0.4 update statements execution was optimized. This optimization changed behaviour of affected rows count retrieval for tables with triggers. If a trigger performs modifications of other records reacting on a modification in the underlying table, SQL Server sends several values of affected rows count (including for modifications made by the trigger). Prior to SDAC 4.00.0.4 the first value was considered as affected rows count, when in SDAC 4.00.0.4 and higher - the last value. However neither of these two approaches can be considered correct, as there can be triggers that snap into action both before modification and after modification. There is no way to determine which of the values returned by SQL Server is the correct value of affected rows count. Therefore we do not recommend using the RowsAffected property when updating tables with triggers.
StrictUpdate mode is based on RowsAffected, therefore we also do not recommend using StrictUpdate when updating tables with triggers.
If you want to disable this optimization, set the __UseUpdateOptimization variable to False.
Set TCustomMSConnectionOptions.UseWideMemos to False to disable mapping of NText database data type to ftWideMemo data type.
Starting with SDAC 3.70.1.26 preparing and the first call of a stored procedure were combined for performance optimization. This requires the necessity of setting the parameter type and data type of all parameters before preparing. In order to revert the old behaviour with preparation and parameters, the OLEDBAccess unit should be added to the uses clause of a unit in an application, and the following line should be added to the initialization section of the unit:
ParamsInfoOldBehavior := True.This variable has sense for Delphi 2009 and higher.
Set its value to True to use the AsAnsiString property when setting the parameter value through TDAParam.AsString. Otherwise the AsWideString property is used. The default value is False.