I have quite an incredible situation using a TADOQuery against an MS Access database.
In the following code (just a test case), the first execution of the query returns the correct record, the second execution instead returns an "empty" record (i.e. the codFormula variable first time is 'E0275', second time is '').
Obviously the three parameters value are the same
QryDosaggioTestata.Parameters[0].Value := idBatchRottura;
QryDosaggioTestata.Parameters[1].Value := nrMiscelataRottura;
QryDosaggioTestata.Parameters[2].Value := dataBatchRottura;
QryDosaggioTestata.Open;
// Here, QryDosaggioTestata's RecordCount is 1 and Eof is False
codFormula := trim(QryDosaggioTestataCodiceFormula.Value);
//now codFormula = 'E0275'
QryDosaggioTestata.Close;
QryDosaggioTestata.Parameters[0].Value := idBatchRottura;
QryDosaggioTestata.Parameters[1].Value := nrMiscelataRottura;
QryDosaggioTestata.Parameters[2].Value := dataBatchRottura;
QryDosaggioTestata.Open;
// Here, QryDosaggioTestata's RecordCount is 0 and Eof is True
codFormula := trim(QryDosaggioTestataCodiceFormula.Value);
// now codFormula = ''
Ora := QryDosaggioTestataOra.Value;
QryDosaggioTestata.Close;
The query text is in the designer object:
Select * from LOG_FINE_DOSAGGIO
WHERE
idBatch = :parIdBatch
AND nrMiscelata = :parNrMiscelata
AND Data = :parData
Obviously the query is syntactically correct, otherwise it would not execute well the first time.
Thanks a lot.
After many attempts I got the clue: the Microsoft JET OLEDB 4.0 provider deals horribly with date parameters: the only way to make it work is, for date parameters, to set the parameter datatype to ftString and to pass the value as DateToStr(yourDate).
My impression is that after first query.Close, the query parameters are re-prepared in the wrong way by the provider.
Hope this helps anyone.
Everything works well with other parameters type (i.e. integer, string...) and with SQL Server provider.
Related
I am using TAdoQuery with BatchOptimistic lock type. If the select command has some fields that are calculated on database server the returned fields has property ReadOnly = true, so i must change them to false so i can modify them in my query.
I am actually never attempting to post to database, but i must use TAdoQuery.
Its all good to the point I append or insert some record, set its fields, and then call for example TAdoQuery.Last, Next or First.. The appended records fields change to null. Please, is there a way that these records could stay as they were?
I am attaching a simple code here, where the problem is presented:
// .. lockType = Batchoptimistic so TAdoQuery.first or TAdoQuery.last do NOT post do database
ADOQuery1.LockType := ltBatchOptimistic;
ADOQuery1.SQL.Text := 'SELECT 10 AS id, 20 AS sid ';
ADOQuery1.Open;
// .. readOnly = false so i can modify these two fields in appended record
ADOQuery1.FieldByName('id').ReadOnly := false;
ADOQuery1.FieldByName('sid').ReadOnly := false;
ADOQuery1.Append;
ADOQuery1.FieldByName('id').AsInteger := 5;
ADOQuery1.FieldByName('sId').AsInteger := 5;
// if use last, first etc. the appended record fields will change to 0 (null)
ADOQuery1.Last;
I am trying to connect my database (Advantage 7.1 Server) using the Advantage OLE DB provider. So far so good...It connects with no problem with the code below:-
const
// the database we'll be connecting to
ConnectionString = 'Provider=Advantage OLE DB Provider;Data Source=C:\Data\'+
'UsersData.add;ServerType=ADS_REMOTE_SERVER|ADS_LOCAL_SERVER;User ID=ISUsers;Password=aAoO31';
My problem is, even though I'm able to connect to the database, any field with AUTOINC as the data type does not generate next numbers. "ID" as AUTOINC keeps on giving me zero (0) anytime I append the data instead of moving to the next number 1, 2, 3.... But for the same code if I switch to MS ACCESS, it works perfectly. What am I doing wrong? please find code below.
// Add template to database. Returns added template ID.
function TDBClass.addTemplate(template: TTemplate): Integer;
var
rs: TADODataSet;
tptStream: TMemoryStream;
id: Integer;
p: PChar;
begin
// get DB data and append one row
rs := TADODataSet.Create(nil);
rs.Connection := connection;
rs.CursorType := ctStatic;
rs.LockType := ltOptimistic;
rs.CommandText := 'SELECT * FROM enroll';
rs.Open();
rs.Append();
tptStream := TMemoryStream.Create();
// write template data to memory stream.
SafeArrayAccessData(template.tpt, Pointer(p));
tptStream.write(p^, template.size);
SafeArrayUnaccessData(template.tpt);
// save template data from memory stream to database.
(rs.FieldByName('template') as TBlobField).LoadFromStream(tptStream);
// update the database with added template.
rs.post();
// get the ID of enrolled template.
id := rs.FieldByName('ID').AsInteger;
// close connection
tptStream.Free();
rs.Close();
rs.Free();
addTemplate := id;
end;
You should consider using the TADSConnection, TADSQuery, etc. components that you can still download from the DevZone (http://devzone.advantagedatabase.com/dz/content.aspx?key=1) even for ADS 7.1.
If you have to use ADO, you probably have to use a different approach. (But see also bummi's comment about a possible bug in Delphi).
One way would be to use the LASTAUTOINC scalar function:
INSERT INTO
enroll
(
template
)
VALUES
(
:template
);
SELECT
LASTAUTOINC(CONNECTION) AS "id"
FROM
system.iota
In Delphi ADO you can pass more than 1 statement in your SQL query string - This might true for ADO in general.
Insert into test (text) Values('ddd'); Select * from test where AutoIncColumn = Scope_identity()
This will return the inserted row with the Autoinc value
or if you need just the autoinc value
Insert into test (text) Values('ddd'); Select Scope_identity() AutoIncColumn
I'm using a MS Access database, with the following columns in the Admins table:
Column Type
====== ====
Name Text
Surname Text
Dateadded Date/time
Adminnumber Number(long integer)
Password Text
ID type Autonumber (Not sure if ID is relevant)
This is my code but it keeps giving me a syntax error.
ADOquery1.Active := false;
adoquery1.sql.Text := 'insert into Admins(Name, surname, Adminnumber, Dateadded,password)Values('''+edit11.Text+''', '''+edit12.text+''', '''+edit13.Text+''', '''+edit14.Text+''', '''+edit15.text+''')';
ADOquery1.ExecSQL;
Adoquery1.SQL.Text := 'select * from Admins';
ADOquery1.Active := true;
i have been trying for a day to figure it out but its the same error no matter what code i use. The error is
Project project1.exe raised exception class eoleException
with message 'Syntax error in INSERT INTO statement'.
i have also tried:
ADOquery1.SQL.Add('Insert into admins');
ADOquery1.SQL.Add('(Name , Surname, Dateadded, Adminnumber, Password)');
ADOquery1.SQL.Add('Values :Name, :Surname, :Dateadded, :adminnumber :Password)');
ADOquery1.Parameters.ParamByName('Name').Value := edit11.Text;
ADOquery1.Parameters.ParamByName('Surname').Value := edit12.Text;
ADOquery1.Parameters.ParamByName('Dateadded').Value := edit13.Text;
ADOquery1.Parameters.ParamByName('Password').Value := edit14.Text;
ADOquery1.Parameters.ParamByName('Adminnumber').Value := edit15.Text;
ADOquery1.ExecSQL;
ADOquery1.SQL.Text := 'Select * from admins';
ADOquery1.Open ;
But this code gives me a problem with the from clause
The problem is that Name (and possibly Password) is a reserved word in MS Access. It's a poor choice for a column name, but if you must use it you should escape it by enclosing it in square brackets ([]). You're also missing an opening parenthesis (() after your VALUES statement, and a comma after the :adminnumber parameter.
ADOquery1.SQL.Add('Insert into admins');
ADOquery1.SQL.Add('([Name] , [Surname], [Dateadded], [Adminnumber], [Password])');
ADOquery1.SQL.Add('Values (:Name, :Surname, :Dateadded, :adminnumber, :Password)');
ADOquery1.Parameters.ParamByName('Name').Value := edit11.Text;
ADOquery1.Parameters.ParamByName('Surname').Value := edit12.Text;
ADOquery1.Parameters.ParamByName('Dateadded').Value := edit13.Text;
ADOquery1.Parameters.ParamByName('Password').Value := edit14.Text;
ADOquery1.Parameters.ParamByName('Adminnumber').Value := edit15.Text;
ADOquery1.ExecSQL;
ADOquery1.SQL.Text := 'Select * from admins';
ADOquery1.Open;
(The error can't be moving around, as you say in the comments to your question. The only line that can possibly cause the problem is the ADOQuery1.ExecSQL; line, as it's the only one that executes the INSERT statement. It's impossible for any other line to raise the exception.)
You should make some changes here that are pretty important to the maintainability of your code.
First, break the habit immediately of using the default names for controls, especially those you need to access from your code later. You change the name by changing the Name property for the control in the Object Inspector.
It's much easier in the code to use NameEdit.Text than it is to use Edit1.Text, especially by the time you get to Edit14. It would be much clearer if Edit14 was named PasswordEdit instead, and you'll be happy you did six months from now when you have to change the code.
Second, you should avoid using the default variant conversion from string that happens when you use ParamByName().Value. It works fine when you're assigning to a text column, but isn't really good when the type isn't text (such as when using dates or numbers). In those cases, you should convert to the proper data type before doing the assignment, so that you're sure it's done correctly.
ADOQuery1.ParamByName('DateAdded').Value := StrToDate(DateEdit.Text);
ADOQuery1.ParamByName('AdminNumber').Value := StrToInt(AdminNum.Text);
Finally, you should never, ever use string concatenation such as 'SOME SQL ''' + Edit1.Text + ''','''. This can lead to a severe security issue called SQL injection that can allow a malicious user to delete your data, drop tables, or reset user ids and passwords and giving them free access to your data. A Google search will find tons of information about the vulnerabilities that it can create. You shouldn't even do it in code you think is safe, because things can change in the future or you can get a disgruntled employee who decides to cause problems on the way out.
As an example, if a user decides to put John';DROP TABLE Admins; into edit14 in your application, and you call ExecSQL with that SQL, you will no longer have an Admins table. What happens if they instead use John';UPDATE Admins SET PASSWORD = NULL; instead? You now have no password for any of your admin users.
I am using Delphi 7 with the FibPlus components . One of them being TpFIBQuery.
I am loading data from a table with the generic
select * from TableName where Key = 1
One of the fields returned is of type BLOB(Text).
I can't seem to get the value into a string list informatie using either of the following 3 ways :
Informatie.Text := FieldByName('Informatie').AsString // Returns the string 'BLOB'
Informatie.Text := BlobAsString('Informatie') // Returns ''
BlobToStrings('Informatie',Informatie) // Returns ''
I have confirmed using Database Workbench that the field in the table indeed contains the saved text.
Anyone ?
usualy, i do like this
var
sl: TStrings; // blob IS NOT string!
ms: TMemoryStream;
begin
sl := TStringList.Create;
ms := TMemoryStream.Create;
try
q.FieldByName('x').SaveToStream(ms);
ms.Position := 0;
sl.LoadFromStream(ms);
// do what ever you want with sl here
// and here too
finally
sl.Free;
ms.Free;
end; // try..finally
end;
note that q is your TpFibQuery object.
also
select * from table is bad bad practice.
that habit eventually will lead you continuous headache.
After trying the solution of #jiang, which produced the same error, I finally have found the culprit.
Turns out it was an error due to my part ( it usually is, you just have to find it ).
Turns out I had set the read transaction to False sometime during the processing/reading of the fields of the original query.
I perform a lookup in another table to get the description of a integer value in the query.
This lookup query uses the same read transaction , and sets this transaction to False after looking up the description.
AFter returning to the original query, reading integer and string fields pose no problem (although the read transaction has been set to False), but reading a BLOB field into a string with the ...AsString method produces an error or returns 'BLOB'.
Obviously I need to set the read transaction to True at the start of the read actions and set it to False after ALL read transactions. This is the major change when you convert a Paradox BDE application to a Firebird of Sqlserver application.
Anyway, I am glad I have found the solution. Hopefully it will help others too.
I have a TClientDataSet with several records, and I want o load all the records, but load the blob field on Demand, one at a time.
I noticed that calling FetchBlobs twice fetches the blob twice and also that checking the field's IsNull property always returns False.
So the only solution I found so far is to access a property like Value or BlobSize and if the blob has not been fetched an exception is raised EDBClient with message "Blob has not been fetched", so if this exception is raised I call the FetchBlobs.
Is there some better way of doing this?
try
cdsIMG.BlobSize;
except
on E: EDBClient do
cds.FetchBlobs;
end;
I'm not sure if this is 100% correct but it's the best I could do. See for yourself.
type
THackCustomClientDataSet = class(TCustomClientDataSet);
function IsBlobFetched(DataSet: TCustomClientDataSet; BlobField: TField): Boolean;
var
I: Integer;
Status: DBResult;
BlobLen: Cardinal;
begin
Result := False;
BlobLen := 0;
with THackCustomClientDataSet(DataSet) do
if Assigned(DSCursor) and (ActiveBuffer <> nil) then
begin
Status := DSCursor.GetBlobLen(ActiveBuffer, BlobField.FieldNo, BlobLen);
case Status of
DBERR_NONE:
Result := True;
DBERR_BLOBNOTFETCHED:
;
else
Check(Status);
end;
end;
end;
There seems to be DBERR_BLOBNOTFETCHED defined in DSIntf unit to be returned by GetBlobLen in case the blob has not been fetched yet. So that return code means 'blob not fetched', success return code means 'blob fetched already', and any other error code probably indicates some other error.
Inspired by TCustomClientDataSet.CreateBlobStream.
If you had to know if a blob's data had been retrieved, I believe, TOndrej's answer would be the way to go. But you don't have to..
When poFetchBlobsOnDemand is set in 'DataSetProvider's options, and FetchOnDemand is set on the 'ClientDataSet', the behavior is already as you describe. I.e. the client data set calls FetchBlobs only if the blob data has not already been retrieved and only when it is needed.
From "Provider.TProviderOption Enumeration":
poFetchBlobsOnDemand BLOB fields are
not included in data packets. [...] If the
client dataset's FetchOnDemand
property is true, the client requests
these values automatically. [...]