I'm attempting to add an index to a fairly large (1.2 million records) DBase 7 table with memo fields.
When I add the first 2 indexes, it works with no problem. However, when I attempt to add the 3rd index, which is a one field index with no options or descfields, I get the following access violation:
Access violation at 0x00400007: write of address 0x00a43820
I've traced through DBTables and it fails on Check(DbiAddIndex(DBHandle, Handle, nil, nil, IndexDesc, nil)); in TTable.AddIndex.
I've tried tracing into DbiAddIndex, but it's part of the BDE module, and I don't have the .pas or a .dcu with debug symbols.
Did you set MAXBUFSIZE to the maximum of 65535 in the BDE Administrator under Configuration\System\INIT ?
It solved my problem when using TTable.AddIndex.
Related
I'm using Delphi 10.2 and the Native Excel 3 library to create spreadsheets.
I have the following code:
var
fWorkbook: IXLSWorkbook;
fSheet1: IXLSWorksheet;
begin
fWorkbook:=TXLSWorkbook.Create;
fSheet1:=fWorkBook.Sheets.Add;
fSheet1.Range['A1','A1'].ColumnWidth:=20;
fSheet1.Range['B1','B1'].ColumnWidth:=20;
fSheet1.Range['C1','C1'].ColumnWidth:=32;
fSheet1.Range['D1','D1'].ColumnWidth:=32;
fSheet1.Range['E1','E1'].ColumnWidth:=14;
fSheet1.Range['F1','F1'].ColumnWidth:=14;
fSheet1.Range['G1','G1'].ColumnWidth:=14;
fSheet1.Range['H1','H1'].ColumnWidth:=14;
fSheet1.Range['I1','I1'].ColumnWidth:=14;
fSheet1.Cells[1,1].Value:='Entry Type';
fSheet1.Cells[1,2].Value:='Intacct Acct #';
fSheet1.Cells[1,3].Value:='Intacct Acct # Description';
fSheet1.Cells[1,4].Value:='Store Name';
fSheet1.Cells[1,5].Value:='Department #';
fSheet1.Cells[1,6].Value:='Location ID';
fSheet1.Cells[1,7].Value:='Project ID';
fSheet1.Cells[1,8].Value:='Grant ID';
fSheet1.Cells[1,9].Value:='Net Amount';
intRow:=fWorkBook.SaveAs(Outfile);
'there is additional code after this.
end;
This code works every time on my development system. I've also used nExcel in other projects without a problem.
However, at the client's system, the fWorkbook.SaveAs generates an "Invalid Pointer" error or Access Violation. Since I cannot duplicate it, debugging is tough.
I have tried moving the SaveAs to various places (after the initial create, after the setting of column widths and where it is now).
Anyone seen this and/or have an explanation?
Thanks!
Malcolm
This problem was resolved by saving the workbook as an xlsx.
We are upgrading our Working Delphi App from Delphi 10 Seattle to Delphi 13.3.3 Rio - SQL Server Db Column with Space(s)
The code associated with this issue works as intended in Delphi 10 Seattle and SQLServer.
The problem is that the Column "Image Type" has a space in its name.
I am looking to solve the space in column names for ClientDataSet and SimpleDataSet
This applies to other table that we have. I know that a parameterized SQL would work as a workaround.
The following Insert SQL Execute statements work as intended.
INSERT INTO tblImages ("Line","Image Type","Image") VALUES ('1','jpg','imageBlobValue')
or
INSERT INTO tblImages ([Line],[Image Type],[Image]) VALUES ('1','jpg','imageBlobValue')
The following Insert via ClientDataSet Does not
//Query
SQLQueryInsert.Cose;
SQLQueryInsert.SQL:='SELECT "Line","Image Type","Image" FROM tblImages';//Oracle & Other SQLs
SQLQueryInsert.SQL:='SELECT [Line],[Image Type],[Image] from tblImages';//SQLServer
SQLQueryInsert.Open;
//Set Non parameterized values
//DataSet
ClientDataSettblImages.Close;
ClientDataSettblImages.Open;
ClientDataSettblImages.Insert;
ClientDataSettblImages['Line']:='1';
ClientDataSettblImages['Image Type']:='jpg';
ClientDataSettblImages['Image']:='imageBlobValue';
//Apply Updates
ClientDataSettblImages.Post;
If ClientDataSettblImages.ChangeCount > 0 then
Begin
ClientDataSettblImages.ApplyUpdates(-1);
End
If I look at the text output of SQLMonitor I can see the following:
Error: SQL State: 1, SQL Error Code: 156, Level: 15, Procedure: , Line: 2
Incorrect syntax near the keyword 'Type'.
ClientDataSet & SimpleDataSet have the same issue. I can see that the problem is the column with the space called "Image Type". The insert via the ClientDataSet works fine without the column "Image Type".
This either looks like a ClientDataSet bug or I'm missing a simple detail somewhere.
Looks like the answer is to add the following Parameter to SQLConnection: UseQuoteChar=True. The Application is now working as intended.
I am using Delphi 2009 Unicode and Firebird 3.x UTF8/dialect 3 database with IBX components. And now I see that all the exceptions raised from the Firebird SQL procedure and trigger code (e.g. using exception my_exception; statement) are handled by IBX as special Firebird exceptions:
Attempt to execute an unprepared dynamic SQL statement
Error Code: 335544711 SQL Code: -901
IBX does not report the name/code/content of the original Firebird exception. It is quite strange, because Delphi 2009 IBX can handle Firebird 2.1 UTF8/Unicode exceptions without problems. It seems to me that IBX is trying to do some extra steps that are not allowed.
Of course, I know that all the advices to move to other frameworks from the IBX, but we are not living in the ideal world, so, the question is as it is.
Question extended:
After initialization code in the project file (this is IB routine http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/IB_SetIBDataBaseErrorMessages.html):
SetIBDataBaseErrorMessages([ShowSQLCode,ShowIBMessage,ShowSQLMessage]);
I am getting normal error messages from the exceptions that are raised from the triggers, but I am still getting generic 'Attempt to execute...' error message in the case when exception is raised from the SQL procedure.
Question updated:
The generic exception about attempt appears when the procedure is called from the IBX TIBStoredProc, but if stored procedure is called (via select from...) from the TIBDataSet, then the right error message appears. So - there should be problem how TIBStoredProc handles the error messages.
Debug shows, that Delphi IBX code IBSQL.pas contains code:
SQLExecProcedure:
begin
fetch_res := Call(FGDSLibrary.isc_dsql_execute2(StatusVector, TRHandle,
#FHandle, Database.SQLDialect, FSQLParams.AsXSQLDA,
FSQLRecord.AsXSQLDA), False);
if (fetch_res <> 0) then
begin
if (fetch_res <> isc_lock_conflict) then
begin
{ Sometimes a prepared stored procedure appears to get
off sync on the server ....This code is meant to try
to work around the problem simply by "retrying". This
need to be reproduced and fixed.
}
FGDSLibrary.isc_dsql_prepare(StatusVector, TRHandle, #FHandle, 0,
PByte(FProcessedSQL.Text), Database.SQLDialect, nil);
Call(FGDSLibrary.isc_dsql_execute2(StatusVector, TRHandle,
#FHandle, Database.SQLDialect, FSQLParams.AsXSQLDA,
FSQLRecord.AsXSQLDA), True);
end
else
IBDataBaseError; // go ahead and raise the lock conflict
end;
end
and the error message about unprepared statement is raised exactly upon the second execution isc_dsql_execute2(...), so - maybe such second try is not necessary and we can raise Exception IBDataBaseError whenever the fetch_res is not 0? Maybe someone knows why Jeff introduced such second call and what bugs this second call tried to solve?
It appears, that Delphi XE 10.2 code makes the second call only in the specific case:
if (fetch_res = isc_bad_stmt_handle) then
And that makes the erroneous second call rare enough to solve the problem in my question. So, the solution is to replace the initial general condition (fetch_res <> isc_lock_conflict) with the more specific condition (fetch_res = isc_bad_stmt_handle).
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 have the following error in the Firebird Database. version 2.5.2
invalid request BLR at offset 163
function F_ENCODEDATE is not defined
module name or entrypoint could not be found
Error while parsing procedure GETMONTHSBYYEAR's BLR
Until last week everything was functioning correctly. This UDF exists on the disk. How can I debug this problem? Anyone can help me to sort out this problem.
PS: What I did so far to fix:
Backup / restore - no result. (any structure problem is fixed in my opinion after a BK/Restore).
Comment all dependencies, drop UDF function, recreate again - no result.
Potential problems could be that he UDF dll is inaccessible for the server (eg due to permissions, or the UDF restriction config in firebird.conf), or you have installed a 64 bit version of Firebird and your UDF is 32 bit (or vice versa), so Firebird cannot load the DLL.