weirdo12

I realize a solution was found, but disabling the ListView when the user changes the contents of the Memo would ensure users remember to save or discard changes.

The FireDAC docs say it's a driver issue. Is your application 32-bit or 64-bit?

Do you have another tool installed on the new laptop that you can successfully use to connect to and view the data in the .accdb file?

A TFDEventAlerter creates it's own new connection when you set the Connection property. So yes, you need to keep track of the TFDEventAlerter objects you create and disable them if the connection is lost. I found it necessary to set Active to false and clear the Connection property. https://docwiki.embarcadero.com/Libraries/Athens/en/FireDAC.Comp.Client.TFDCustomEventAlerter.Connection

Wow. That's looks like a great tool to help new Delphi developers get started.

In the direction Remy suggested, maybe TFDConnection,Connected = true in the IDE.

What database are you using? Show us the code you are using that is not working as expected along with an explanation of what you think should be happening.

The warning is caused by having #include "Label.h" *before* the USEFORM. #include "Label.h" ... USEFORM("Label.cpp", fmLabelView); Try this: USEFORM("Label.cpp", fmLabelView); ... #include "Label.h"

Thanks for the update.

If you want to be as flexible/portable as possible you could consider using a FireDAC macro like this: email = { fn IFNULL(:EMAIL, email) }

😄 So just supply the current value when the value doesn't change. I do like the statement that uses COALESCE because it makes it very obvious that that is what is happening. Are you targeting a specific database server?

They are retooling the C++ compiler chain. I get the impression that C++ is becoming more important - not less - even if it might seem like a 2 steps forward, one step back (for the moment). My gut feeling is the future has never been brighter for C++Builder.

Why not just supply the current value where you don't want a value to change?

Thank you, Roger.

We still use an old Northern Telecom phone system and have an operational fax machine on a stand alone line here at work here in Toronto. 😄

Great to hear that things are getting fixed up!

I'm still surprised it hadn't been mentioned already as a possible cause...

I just did a search of the terms 'ransom' and 'ransomware' and they haven't appeared in this thread. I'm kinda surprised. 😉 You'd think that the documentation would be back up by now.

Thanks for the update.

You can build your file name like this as well: var file_name : String; file_name := TPath.Combine('D:\Delphi_11_Community\MyProjects\Dinobase\dino_images', sName); file_name := TPath.ChangeExtension(file_name, "jpg"); dinoImage.Picture.LoadFromFile(file_name);

Drop a TFDQuery component on your form. If it's the first one, it will be named FDQuery1. Set FDQuery1.Connection property to the TFDConnection you use to connect to the SQLite database. Then, in your code, replace Query. with FDQuery1.

In the version that works, what happens if you don't call fdqImportData .Close after copying the data to the TFDMemTable?

I'm glad you found a solution. You could have a look at this thread and see if there's anything that might help with the original problem:

And you are using the MARS=Yes parameter on the connection? Have you tried version 17 of the SQL Server ODBC driver?

Try executing you commend on your TFDConnection and see what you get: FDConnection1.ExecSQL('UPDATE dbo.TDexAllocationTicketOut SET ReadDT = GETDATE() WHERE IDInt = :idInt', [fdqImportData.FieldByName('IdInt').AsInteger]); You might have to fix my Pascal. I didn't test it.