Jump to content

krayna

Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. krayna

    FireDac with Postgres and Prepare()

    Yes, I know this, but with Firebird it was no problem even if I didn´t set the data type before calling prepare. It´s a big project and I would have to change a lot of code for this. I just wondered why this was never an issue with Firebird and now it´s a problem with PostgreSQL.
  2. When I use FireDac with PostgresSQL and call "myQuery.Prepare()", I often have the problem that I have to define the param data type. Is it possible to have the data type of a parameter assigned automatically? qryWork.SQL.Text := 'select distinct(field1) from config c where c.field1 = :Name'; qryWork.Prepare(); // Here, I get the error, that data type of parameter 'Name' is unknown The same code with Firebird was never a problem. Is there a setting for this? And why can Firebird (or the FB driver) handle this and Postgres can not?
  3. krayna

    DElphi XE 10 FireDac

    FireDac is more strict especially with certain databases like SQLite, where the semicolon as the end of the statement can generate syntax errors. Search/replace of the sql statements (with regex) is not an option for you? Alternatively you could create a descendant of TFDQuery and override ExecSql where you delete the semicolon at the end of sql.text. In this case you have to replace your TFDQuery objects with TFDMyQuery of course but you don't need to change the rest of the code.
  4. krayna

    Share FireDac Tables over DLL boundries

    Thank you very much for the detailed answer and for the explanation!
  5. Hello everyone, I am in the process of converting an old project from Bde to Firedac. Basically it's relatively easy, but now I'm at a point where I'm a bit desperate. With the Bde, TDatabase and TTable/TQuery components, I had set up a central connection in my main program and opened all the necessary TTable tables. Now DLLs of the program (dynamically loaded with LoadLibrary) could call a function in the central location (export method) and, for example, fetch a TTable object corresponding to a specific table. Regardless of whether the design is good or bad, it worked without any problems. We used "ShareMem" in the main application and all the DLLs. I then had access to the tables of the main program in the DLL and could, for example, call FindKey to jump to a specific position in the DB. With Firedac I left everything as it was, only instead of TDatabase I used TFDConnection and accordingly TFDTable etc. The code is definitely correct, I can connect and display the data in the Dbgrid. FindKey from the main program also works. Nevertheless, I always get false with FindKey from the DLL after I have fetched the TFDTable. Does anyone have any experience with this? Could it be that the connection does not arrive correctly in the DLL when I get the TFDTable object? On the other hand, something like fdtable.fieldbyname(...) works without problems from the DLL. So I don't understand why FindKey doesn't work. It is also the same TFDTable object that I get back from my main application, indexfieldnames is also correct, table and connection are open and everything. Nevertheless it does not work. Would be grateful for a hint, especially since it works with TTable. I hope I was able to explain the problem. FindKey was just an example, I´m not sure, if other methods called in the dll work properly either. The Idea behind this concept is that we have a central place and all DLLs have access to the main tables and can change the cursor position of the table or can be updated when another DLL changes the position of a table, because they all use the same tables from the main application. Is there a better concept for this in FireDac with DLLs? Or do I need to create methods in my main application for Table updates or methods like "FindKey" which can be called from the DLLs? That would be a huge refactoring and I want to avoid this! Thanks a lot!
×