weirdo12

There is an TFDConnection property that you can set to tell it how use/save the state of the Connected property - ConnectedStoredUsage.

Did you try including the schema name with the table name? vTable.TableName:='test_schem.test_table';

If you use the public schema does everything work as expected? I just want to confirm that. I am assuming it does. You don't assign any value to SchemaName and everything works. Or do you assign 'public' to SchemaName?

Thanks, Lars.

Nice. The only issue would be if any of the columns is NULL.

Have you tried this setting? It's just a shot in the dark.

Or: SELECT SUM( if( (if(col1 = 'True', 1, 0) + if(col2 = 'True', 1, 0) } + if(col3 = 'True', 1, 0) ... ) > 0, 1, 0) ) AS "Some Columns Have True Strings" FROM ...

How about: SELECT if(col1 = 'True', 1, 0) + if(col2 = 'True', 1, 0) } + if(col3 = 'True', 1, 0) } ... AS "Sum Of True Strings" FROM ...

If the TDFBatchMove.Reader property is a TFDBatchMoveTextReader when GuessFormat is called, how many rows does it read from a file to determine the format of the columns? The issue I have is an import file where a column normally has the value 1 and then say 10,000 rows in it will change to 2.2046 which kills the import.

Yep. That particular property did not elude me.

Oh boy, how did I miss that TFDBatchMove.AnalyzeSample property!? After more thought this morning, I doubt it's going to help with my problem. For example if the text file was like like this: "row_id","float_col" 1,1 2,2.2046 3,1 float_col will likely still be guessed to be an integer. I will have to look at the source.

I assume you figured this out, eh?

1. Open the project. 2. Open the TDataModule source file. 3. Change the Name property of the TDataModule to a new unique name. 3. Click File > Save As... and save it with a new file name. 4. Add the original TDataModule back to the project. In the new TDataModule you can start deleting components and event handlers. 1. Select the component you want to delete. 2. In the Object inspector, click the Events tab. 3. For any events that have been created for the component, double-click the event handler name. 4. Delete the code within the event handler BUT DO NOT delete the event handler. procedure TForm1.DataSource1DataChange(Sender: TObject; Field: TField); begin // delete the code in here but // leave everything between procedure and end; end; 5. Click File > Save and the handler will be removed.

I should have said that an alternative way is to use IndexFieldNames instead of queries with parameters. Both methods produce the same results.

IndexFieldNames in Query2 and Query3 should be set to CUSTNO. A parameter is not required. Query3.SQL = ' SELECT CUSTNO, sum(AMOUNTPAID) as TOTAL from ORDERS GROUP BY CUSTNO';

If you are using TFDQuery, have you tried using the MasterSource property to connect Query2 to Query1? Query2.IndexFieldNames = fk_id_employee Query2.MasterFields = id Query2.MasterSource = Query1 You can use TFDLocalSQL and a TFDMemTable to do a summary of Query2.

Column LN does not exist in fdToTable. It may exist in your database but it's not in the table objects field collection.

Use TFDScript with just the INSERT and DELETE statements.

Excellent!

Why are you using dbExpress? Is it an existing application that worked properly with another version of C++Builder?

Done. https://quality.embarcadero.com/browse/RSP-40382

This might be of some help to Dmitry I suppose. These also work: SELECT * FROM wares$rules "wares$ rules$" WHERE fldidxwarerule = :dummy_string_param SELECT * FROM wares$rules "wares $ rules $" WHERE fldidxwarerule = :dummy_string_param SELECT * FROM wares$rules "$" WHERE fldidxwarerule = :dummy_string_param SELECT * FROM wares$rules "$$$$" WHERE fldidxwarerule = :dummy_string_param SELECT * FROM wares$rules "$ $" WHERE fldidxwarerule = :dummy_string_param But these do not: SELECT * FROM wares$rules "$$" WHERE fldidxwarerule = :dummy_string_param SELECT * FROM wares$rules "$$$" WHERE fldidxwarerule = :dummy_string_param

To summarize/simplify... These work: SELECT * FROM wares$rules "wares$rules$" SELECT * FROM wares$rules WHERE fldidxwarerule = :dummy_string_param SELECT * FROM wares$rules "wares$$rules$$" WHERE fldidxwarerule = :dummy_string_param But when there is more than one single $ in the table name and there is a parameter in the query it does not: SELECT * FROM wares$rules "wares$rules$" WHERE fldidxwarerule = :dummy_string_param [FireDAC][Phys][PG][libpq] ERROR: syntax error at or near ":"

I am not seeing that problem with PostgreSQL 14.5 using FireDAC. This works fine too: SELECT "$$1$$".row_id, "$$1$$".description, :dummy_string_param, :dummy_int_param FROM t$1$$$$$$$$$ "$$1$$" LEFT OUTER JOIN "t1$t2$t3" ON "$$1$$".row_id = "t1$t2$t3".row_id Edit: This gives me a syntax error - only when parameters are included (which makes some sense): SELECT "$$1$$".row_id, "t1$t2$t3".row_id, "$$1$$".description, :dummy_int_param FROM t$1$$$$$$$$$ "$$1$$" LEFT OUTER JOIN "t1$t2$t3" ON "$$1$$".row_id = "t1$t2$t3".row_id [FireDAC][Phys][PG][libpq] ERROR: syntax error at or near ":" This works: SELECT "$$1$$".row_id, t1.row_id, "$$1$$".description, :dummy_int_param FROM t$1$$$$$$$$$ "$$1$$" LEFT OUTER JOIN "t1$t2$t3" t1 ON "$$1$$".row_id = t1.row_id

I was going to point out the Data property but you said you only wanted to discuss CopyDataSet() 😄 Good to hear you've got a solution.