I was using UniDac for a long time now and decided to move on to FireDac as it has good Asynch methods after moving on i saw that none of my data editing works anymore it gives me an error:
[FireDAC][Phys]-330. Cannot generate update query. Update table undefined.
What I am trying to do here is i have a TFDStoredProc component who gets all the data from the database and lets me edit it, with unidac I could easily edit the data without any problem like this:
StoredProc.Edit;
StoredProcCreatedID.Value := SomeValue;
StoredProc.Post;
and it worked, but with AnyDac it doesn't, I tried specifying manually the UpdateTable which leads to another problem:
[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name 'CreatedID'.
I am using Microsoft SQL Server 2012 FireDac 8.0 and stored procedures for getting back results any ideas?
P.S.
The query looks like this
SELECT
CreatedBy as CreatedID,
usr.UserName as CreatedBy
FROM
Sales
LEFT JOIN
Users usr ON usr.ID = Sales.CreatedBy
it looks like the FireDac update builder doesn't recognize the aliases on the fields, any help would be appreciated.
Well i figured out what was the issue, it seems that if you specify a alias in the query for a field the Origin property will be set to the alias and not the real field i downloaded CNPack a must have for a delphi developer also its free, ran the component selector and changed all my aliased fields to their real fields and it works, but this is still a big issue in FireDac component because it doesnt recognize the aliased fields, lets hope it will be fixed in the future as to specify for every query what table it should update and what fields that just allot of work if you are migrating from a big project in my case 220+ stored procedures.
Related
My name is Stefano Fanti,I am a developer in Plexa.We are actually using your component ( FireDAC ) and I am contacting you in order to solve some
problems we have not been able to fix ourself.
In our company we decided to port a legacy 3-Tier DATASNAP application written on Delphi7 for the new environment Delphi XE7 , and we decided to use the new components library FireDAC too.
Our application is built in this way: a Client side using TClientDataSet directly connected to the Server side with TDataSetProvider/MIDAS and TTable TQuery TDatabase components (BDE)
We replaced BDE components with the related FireDAC ( FDConnection , FDTable and FDQuery ) without issues and we started testing thinking anyway it was not needed to perform it.
After some test , a couple of issues have arosen : the first problem is related to the modifications performed on DB ( MS SQL Server ) , the second is related the the reopening of the table after applying the modifications.
In our case , the RequestLive=True property ( default ) , does’nt allow to apply modifications ( Post/ApplyUpdates) to the Database.
Assigning RequestLive = False , we are able to apply modifications on all table’s records except the first, the last giving us the error .
The above anomaly have been verified on each Database table . However all database tables have the primary key defined properly.
Trying to use FireDAC Help I read the option RequestLive=False excludes fiMeta from Fetch,Options, preventing the component to use the primary key of the table, being otherwise seen correctly in any other case.
After several trials I found two configurations applied to the Server side, allowing us to achieve the result.
First configuration
FDTable.RequestLive= False
FDTable.UpdateMode = upWhereKeyOnly
with FProvider.DataSet.FieldByName (pkField) do
ProviderFlags: = ProviderFlags + [pfInKey];
Second configuration
FDTable.RequestLive= False
FDTable.UpdateMode = upWhereAll
TDataSetProvider.UpdateMode=upWhereAll
The above configurations give us the possibility to apply modifications to tables without errors , but nevertheless don’t allow us to solve the second problem : reopening of the tables for each operation. Indeed , the BeforeOpen and AfterOpen managers are executed each time.
What can I do to avoid the Table to be needless reopened after each modification ?
Are the configurations used to apply modifications correct , or maybe another solution exist allowing us to avoid code modifications causing us to lengthen development times ?
Thank you in advance for your help.
Best regards
Stefano Fanti
Since I don't want to use ODBC connections anymore, I'm trying to get DBX work for my reports. Almost everything works the same as it worked with the tfrxAdoQuery, but not the GroupFooter.
I used to have a MasterData that used a ADOQuery1: TfrxAdoQuery and I changed to a DBXQuery1:TfrxDBXQuery. Its fields like [BDXQuery."name"] work fine now than I'm using a different type of query, but only inside the MasterData. This is the way it looks in the MasterData and when the report is displayed it comes correctly:
For some reason, the Footer's tfrxMemoViews dont show the DBXQuery1."anyField" that I try to display.
This is the way it looks in the footer but in the report just dont show the name.
The difference is the DatasetName can't be set for the DBXQuery (as it was set when using the ADOquery). When I was using ADO, the DatabaseName seem to be assinged arbitrarilly with a name like 'header' which did not belong to any component or variable. Now it should be more manageable since the fields that are set are DataSet (wich can be chosen from a group that has all the DataSets, in my case I can choose DBXQuery1) and DataField, which can be chosen from one of the predetermined fields that are in the DBXQuery1.
Any help will be highly appreciated
I am trying to use Macros in FireDAC to Preprocess my SQL Queries. I have a TADQuery object on a Data Module with the SQL set to something like:
Select * from MyTable
join OtherTable on MyTable.Key = OtherTable.Key
&Where
Then in my code I do this:
WhereClause = 'stuff based on my form';
Query.MacroByName('Where').AsRaw := WhereClause;
Query.Open;
This has worked great for complicated queries because it lets me make sure my fields and join conditions are correct using the SQL Property editor.
My problem is when the SQL statements ends up invalid because of my where clause. Is there any way to see the SQL after pre-processing that is going to be executed? Right now I am catching the FireDac errors and showing the SQL that is on EADDBEngineException object. However that is still showing my original SQL with the macros. If I can't get to it after the error happens is there anyway to force the Macro replacement to take place so I can look at the SQL in the debugger to help me see what is wrong.
If it matters I am connecting to a MS Access database with the goal of moving to SQL Server in the near future.
Apart from using Text property, to monitor what SQL is actually going to the database engine, consider using the "FDMonitor" FireDAC utility. According to the DokWiki pages (below):
drop a TFDMoniRemoteClientLink component on your form,
Set its Tracing property to True,
Add the MonitorBy=Xxx connection definition parameter to your existing FDConnection component. You can do this in the IDE object inspector, by selecting your FDConnection component, expanding the Params property, and setting MonitorBy to mbRemote.
Note that the TFDMoniXxxxClientLink should come before TFDConnection in the data module or form creation order, so adjust this by right clicking on the form or data module, then Creation Order, and moving the TFDMoni.. component above the FDConnection.
Also, it's helpful in the options of the TFDMoniXxxxClientLink, to disable most of the events being recorded, otherwise all the data returned is also shown in the FireDAC monitor. Expand the EventKinds property, and turn all the event kinds off, except for perhaps ekConnConnect, ekConnPrepare, and ekCmdExecute.
Then open the FireDAC Monitor from the IDE, (Tools > FireDAC Monitor). Start your app only once the monitor is running. Double click on a trace event (in the Trace Output tab), and you will see the actual SQL sent to the database in the bottom pane.
It also seems likely that adding the EventType of ekConnPrepare as mentioned above, would show you when the query's Prepare is called, but I haven't played enough with it say for sure.
Please see the following pages on the DocWiki for more information:
Overview: FDMonitor
How to: Tracing and Monitoring (FireDAC)
Other FireDAC utilities: Utilities (FireDAC)
(Just to remove this question from list of unanswered questions)
From comments:
Well, I've roughly checked what's happening there and I'm still not
sure if calling Prepare (which is useless for you as I get) is the
minimal requirement to trigger that preprocessing. Though, the
preprocessed SQL, the one which is sent to the DBMS you can access
through the Text property (quite uncommon name for such property). – TLama Feb
21 '14 at 8:18
I have created a report using FastReport Designer (Delphi 2010). I have one TfrxIBXQuery (Query1) connected with main database -Base1(frxIBXComponents.DefaultDatabase:=Base1). It works fine, I can get data using Query1+MasterData band.
The problem arises when I'm trying to get data from another database in the same report.
In Designer I drop new frxIBXDatabase (Base2), set the necessary properties. Add new TfrxIBXQuery (Query2) and connect it with Base2.
But I can't get any data from Query2 because it does not see Base2.
How do I solve this problem?
When you look at the properties tab from your query component, can you see any FieldAliases?
If not, you should check the SQL, FastReport can be really picky when it comes to parameters.
Try changing parameter names and see if that works.
If you want to use two or more databases inside report - you should use two TfrxIBXDatabase inside report (on the Data tab)
Clear frxIBXComponents.DefaultDatabase property
I have a DLL created in Delphi XE2 that is using DB Express and TClientDataSet to display the results of a join in a DB Grid. There is a simple function to launch/show the form that is exported for use in other applications. The query is executed, and the grid populated, on FormActivate.
When I call the function to show the form from a separate Delphi XE2 application, everything runs fine - no issues that I can find.
However, when I call the same function from a separate Delphi 7 application, I get an error that that TClientDataSet can't find fields from the join.
For Example, data is returned like this:
[dbxds == TSQLDataSet
cds == TClientDataSet]
dbxds.commandtext='select s.sfield1, s.sfield2, t.tfield1, t.tfield2 from s left join t on s.sfield1 = t.tfield1';
cds.Open;
cds.fieldByName(sfield2).visible:=false;//to hide from a dbgrid
cds.fieldByName(tfield2).visible:=false;//to hide from a dbgrid
When called from XE2, no issues.
When called from Delphi 7, the last line (used to hide that field from the db grid) gives an error that:
cds: Field 'tfield2' not found
Though the first line is fine - if I switch the order of the query so that that 't' fields are retrieved first ('from t left join s'), then I get the error on the 's' field instead.
Any thoughts on what could be causing the incompatibility?
Thanks!
OK so, I noticed something odd and that put me on the path to getting the answer to this.
It just happened that, in either table, the field I was trying to access to hide was of type 'tinyint(1)'. If I tried to hide a field of type int/varchar etc, no error was thrown.
I swapped my 'tinyint(1)' fields for 'int(1)' and it works fine.
No idea why this was happening, but I'm glad I caught it and, if any one else runs into this issue, I hope that this answers their question for them too.