This code:
FDConnection.Open; // Design time TFDConnection; default settings
TabelGrid.Close; // TDFTable connected to TFDConnection; default settings
TabelGrid.TableName := 'TT_ACT';
TabelGrid.Open;
TabelGrid.Edit;
TabelGrid.FieldByName('TT_NAME').AsString := TabelGrid.FieldByName('TT_NAME').AsString + '*';
TabelGrid.Post;
fails with
[FireDAC][Phys][IB]-312 Exact update affected [0] rows, while [1] was requested
when Firebird 2.5.7 is installed, not when Firebird 2.5.3 is installed.
Call stack:
Conditions:
The TFDConnection points to a local .GDB file, driverID IB or FB, default sysdba password, all default settings. TFDPhysIBDriverLink or TFDPhysFBDriverLink present.
Delphi Tokyo 10.2.3 Win32 code, Windows 7
Firebird installed with option to put gds32.dll in System32; no spurious Firebird DLLs lying around
Interbase not present on system
The table has 3 indices:
TT_I0_ACT TT_ACT_ID Primary
TT_I1_ACT TT_PARENT_ID
TT_I2_ACT TT_FROMDATE
I've fumbled with settings, especially changing the default UpdateOptions.UpdateModes from UpWhereKeyOnly to UpWhereChanged or UpWhereAll, but no results so far.
What can be going on; what else can I investigate?
We distribute Firebird 2.5.3 with our app, but I'm afraid it will fail when clients already have a later version (as we found out when one of our developers upgraded FB).
Additional research:
The query that I see in TFDPhysCommandAsyncExecute.Execute (FireDAC.Phys.pas) for both versions is (with the default UpWhereKey update mode):
UPDATE TT_ACT SET TT_NAME = :NEW_TT_NAME WHERE RDB$DB_KEY = :OLD_DB_KEY
(actually, all FCommand properties show identical in the inspector).
I've looked through the Firebird 2.5.x. release notes and saw only one in 2.5.6 that is somewhat related:
The number of affected rows was reported incorrectly for an update against a view created WITH CHECK OPTION
I'm not sure this applies because it's about views. Setting UpdateOptions.CountUpdatedOptions to false makes no difference.
There's nothing in the 2.5.8 fixes list that indicates that a relevant bug was introduced in versions 2.5.4-2.5.7.
I have traced the FireDAC code to the point where execution differs in 2.5.3 and 2.5.7 but that ends with an interface method that I cannot trace:
TFDTable.InternalPost
TFDDataSet.InternalPost
TFDAdaptedDataSet.DoProcessUpdateRequest(arUpdate
TFDCustomTableAdapter.Update
TFDCustomTableAdapter.UpdateAdapterCmds(const ACmds: array of TFDActionRequest);
ACmds contains (arUpdate, arFetchRow)
back to TFDCustomTableAdapter.Update
TFDDAptTableAdapter.Update
TFDDAptTableAdapter.ProcessUpdate
In the 'build command if required' part
oCmd.SQLText := 'UPDATE TT_ACT'#$A'SET TT_NAME = ?'#$A'WHERE RDB$DB_KEY = ?'
ProcessRequest
in TFDDAptTableAdapter.ProcessRequest
SetParamsFromRow(ACommand.Params, ARow);
AParams.Count=2: NEW_TT_NAME and OLD_DB_KEY. OLD_DB_KEY value is 0 in both cases
then
ACommand.Execute;
TFDPhysCommand.Execute
ExecuteTask
TFDPhysCommand.ExecuteTask
FExecutor.Run
TFDStanAsyncExecutor.Run;
TFDStanAsyncExecutor.ExecuteOperation
FOperationIntf.Execute;
TFDPhysCommandAsyncExecute.Execute
TFDPhysCommand.ExecuteBase
FExecutor.Launched; -> Interface, cannot trace
Process_SingleRow
Process_HandleSystemFailure
InternalExecute -> Interface, cannot trace
This last call returns with var parameter ACount to 1 for 2.5.3, and 0 for 2.5.7
The GetRowCounts function returns
FRowsUpdated,FRowsDeleted,FRowsSelected,FRowsInserted: 1 0 1 0 in 2.5.3
FRowsUpdated,FRowsDeleted,FRowsSelected,FRowsInserted: 0 0 0 0 in 2.5.7
Related
I have installed Zeoslib 7.2.4 because of updating to Delphi 10.2 and after testing my projects the result of SELECT isn't expected. The previous version 7.1.4 Works fine.
The results after updating to 7.2.4:
Connection ClientCodePage is binary. If I change this to utf8 the results will look like this, The Address col is correct but Title is still corrupted:
The database and table collation is latin1_swedish_ci. I don't have a problem with version 7.1.4. One workaround for this problem is this:
TEncoding.Default.GetString(DBQuery.FieldByName('Title').AsBytes)
This is the expected result:
I get the following error on startup after I upgraded from GRAILS 3.3.2 to 3.3.9:
org.apache.tomcat.jdbc.pool.ConnectionPool : Unable to create initial connections of pool.
org.h2.jdbc.JdbcSQLException: Scale($"10") must not be bigger than precision({1});
({1}); SQL statement:
CREATE CACHED TABLE PUBLIC.GAME(
ID BIGINT DEFAULT (NEXT VALUE FOR PUBLIC.SYSTEM_SEQUENCE_6AFE1F30_C0FB_47AD_B2B5_FD6A519957AE) NOT NULL NULL_TO_DEFAULT SEQUENCE PUBLIC.SYSTEM_SEQUENCE_6AFE1F30_C0FB_47AD_B2B5_FD6A519957AE SELECTIVITY 100,
VERSION BIGINT NOT NULL SELECTIVITY 3,
...
FINALROI DOUBLE SELECTIVITY 76,
STATUS VARCHAR DEFAULT 'FINISHED' NOT NULL SELECTIVITY 1
) [90051-197]
This problem only occurs when using an existing H2 database (that contains a lot of data). I tested with setting **dbCreate: create ** and everything works fine then. I also did a comparison of the schema created and it was identical to the one in my actual DB.
I also tested that the break happens with GRAILS 3.3.5. I went though the content of the release and could find nothing that would cause this behavior.
Could someone point me in the right direction? Is there a problem with the data in my database (somehow invalid inserts has happened or something) or is this caused by something else.
EDIT
Has to do with the H2 upgrade to version 1.4.197. Easy workaround is do downgrade by setting the previous version in build.gradle
runtime "com.h2database:h2:1.4.196"
The problem was bad sql which was was not properly validated due to a bug in earlier H2 versions. For some reason the schema contained a statement, where scale > precision:
_TIME TIMESTAMP(23, 10)
Fixed it with a DB conversion.
I'm facing difficulty to find a correct way to get errors on ApplyUpdates method, using FireDAC in memory (CachedUpdates).
Here is my scenario, a master-detail relationship, compounded by:
1 TFDConnection
2 TFDQuery
2 TDataSource
1 TFDSchemaAdapter
Both queries are setted as CachedUpdates and are linked to FDSchemaAdapter.
The FDQuery2 (detail) is linked with the master by MasterSource property. MasterFields and IndexFieldNames are setted as "idMaster". The property FetchOptions.DetailCascade is also checked.
I also have a button to perform the apply:
try
FDConnection1.StartTransaction;
FDSchemaAdapter1.ApplyUpdates(0);
FDQuery1.CommitUpdates;
FDQuery2.CommitUpdates;
FDConnection1.Commit;
except on E: Exception do
begin
FDConnection1.Rollback;
raise Exception.CreateFmt('Something went wrong. Error: %s', [E.Message]);
end;
end;
Everything is working fine so far.
The problem occurs when my database throw an exception, such a constraint violation. The exception is not raising. Consequently, my transaction is not 'rollbacked'.
ps: I'm using Delphi XE7 and Firebird 2.5
As the documentation states:
ApplyUpdates returns the number of errors it encountered. Based on
this return value and the setting of AMaxErrors successfully, applied
updates are removed from the centralized change log. If the update
process is aborted before all updates are applied, any unapplied
updates remain in the change log.
ApplyUpdates does not raise an
exception. Instead, the application should review erroneous records
using Reconcile and the OnReconcileRow event handler or the
FilterChanges and RowError properties for each dataset. For more
details, read "Reviewing errors" at Caching Updates.
So... you should not be expecting an exception but you should be checking the value returned by ApplyUpdates to decide if you can commit or handle errors.
I compiled inno-setup with XE6 myself. (I know, the document suggested older delphi versions, but I only have new IDE)
I want to use pascal script to customize setup. But even I added a simplest [Code] section, the created installation crash.
[Code]
function InitializeSetup(): Boolean;
begin
end;
The created setup.exe failed while being installed:
[22:10:29.945] *** Setup started
[22:10:36.182] Setup version: Inno Setup version 5.5.4 (u)
[22:10:36.186] Original Setup EXE: D:\Classics\Save\Installer\Win_Platform\Inno Setup\test\Output\setup.exe
[22:10:36.190] Setup command line: /SL5="$911152,176640,176640,D:\Classics\Save\Installer\Win_Platform\Inno Setup\test\Output\setup.exe" /SPAWNWND=$7B05B8 /NOTIFYWND=$1150B10 /DEBUGWND=$74002E
[22:10:36.200] Windows version: 6.2.9200 (NT platform: Yes)
[22:10:36.203] 64-bit Windows: Yes
[22:10:36.209] Processor architecture: x64
[22:10:36.212] User privileges: Administrative
[22:10:37.660] 64-bit install mode: No
[22:10:37.674] Created temporary directory: C:\Users\CAOSHU~1\AppData\Local\Temp\is-5AOTJ.tmp
[22:10:37.717] InitializeSetup raised an exception (fatal).
[22:10:37.725] Exception message:
[22:10:37.734] Message box (OK):
Access violation at address 006043C0 in module 'setup.tmp'. Read of address 00000014.
[22:11:03.501] User chose OK.
[22:11:03.515] Deinitializing Setup.
[22:11:04.424] *** Setup exit code: 1
Perhaps the way I compiled inno setup has some problems. I need not use XE6? But how to debug and figure out where the problem is？
It is not some code which crashes when it runs. It is a setup.exe which created by inno setup.
The value returned by InitializeSetup() is undefined.
function InitializeSetup(): Boolean;
begin
result := true;
end;
You get an undefined behaviour because of this. If most of the time the result will be false (last 8 bits of RAX == 0), this is not always the case and you'll get a seriously "hard to understand" issue, particularly when, for no reason, it'll work.
HI I am getting this exception when I am calling any stored procedure from my J2EE app.
Exception while calling stored procedure :Bigger type length than Maximum
I am having Oracle 9.1.0.7, JDK1.4 and using ojdbc14.jar running on Weblogic 8.1
Please advise what could be the root cause ?
Below is the manifest of my ojdbc14.jar
Manifest-Version: 1.0
Implementation-Version: "Oracle JDBC Driver version - 10.1.0.2.0"
Specification-Title: "Oracle JDBC driver classes for use with JDK1.4"
Specification-Version: "Oracle JDBC Driver version - 10.1.0.2.0"
Implementation-Title: "ojdbc14.jar"
Created-By: 1.2.2 (Sun Microsystems Inc.)
Implementation-Time: "Wed Jan 21 00:48:12 2004"
Implementation-Vendor: "Oracle Corporation"
Specification-Vendor: "Oracle Corporation".
It's a driver bug. Your version is already 6 years old. Download the latest and greatest from here.
See this post for a possible workaround.
For possible causes, see this thread:
There are bugs in different versions
of the drivers and different versions
of the database; most of them are
fixed in later versions.
For example, bugs produce the "Bigger
type length than maximum" in Oracle
database 8.1.7.2 or 9.0.1.1 for
certain very specific operations using
DB links; upgrading to 8.1.7.3 or
8.1.7.4 or 9.0.1.2 resolves those problems.
For example, bugs produce the "Bigger
type length than maximum" in Oracle
database 10.1.0.2 and 10.1.0.3 for
certain very specific operations
involving NLS characters; upgrading to
10.1.0.4 pr 10.2.0.1 resolves those problems.
For example, the 8.1.6 classes12.zip
had such a bug on certain operation
with databases in a UNICODE character
set, that was fixed in the 8.1.7.4
driver.
If you have an Oracle support
contract, you can find out this
information on the Oracle support
site; metalink.oracle.com If not,
download the latest versions of the
drivers and pray...
i downloaded the latest driver and now much better - now that all the referenced locations are updated
Another option than you can consider is review your query parameters, specially setFetchSize, if its too high this error is returned.
java.sql.SQLException: Bigger type length than Maximum
There is a maximun size depending on the database in my case 64kb (Oracle) my highest value have to be 65535
Reference document:
https://docs.oracle.com/cd/E11882_01/java.112/e16548/resltset.htm#JJDBC28621