corneliusdavid

Take a look at AutoGetIt.

You need to have the client tools installed on the remote machine, then use gbak like this: gbak -b -user SYSDBA -password masterkey server:/path/to/database.fdb client:/path/to/backup.fbk

I tried this a few years ago with a Delphi XE application and it worked but we decided not to go with it. The client had very few users and I was only charging T&M so this added an ongoing cost they wouldn't have had previously plus they all had Windows desktop computers anyway so they just left it as it was. It was really cool to see it working though.

That'd be great. I have tried Delphi's "Lock Controls" (on the Edit menu) but it only lasts for the current session (when you close and re-load, it's off again) and I don't remember to turn it back on. Also, when using Delphi in DPI-Aware mode, there are still changes even when I don't touch anything; I just pulled up a fairly simple form and closed it without moving anything and 12 lines of changes showed up in my Git diff, half were ExplicitXXX properties because I had the GExperts feature off, the others were ItemHeight, ClientHeight, etc.; Using DPI-Unaware mode, nothing changed (thanks, @JonRobertson for that observation!).

Oh really!? I hadn't thought of that but I'm starting to use DPI Unaware mode more often because there are constant annoying font size changes almost every other time I click on something or pull down a menu. Here is definitely another advantage.

That's interesting. I confirm and tried some variations on the single vs double types in both; my time in milliseconds is shown in the comments: {$IF Defined(WIN64)} t_reel = double; // 2880-2930 ms //t_reel = single; // 2410-2440 ms {$ELSE} //t_reel = double; // 5030-5150 ms t_reel = single; // 1170-1180 ms {$ENDIF}

For me, it still opens GExperts Rename Component expert; and in code view, it opens the GExperts Rename Components Configuration.

I see Top/Left/Width/Height/ClientWidth/ClientHeight change a lot, too--and I'm pretty sure I don't move those components every time I open a form.

Here's my new upgrade process after having so many problems in the past: Disable User Access notifications: I do this temporarily to speed up the process. Uninstall all GetIt Packages: Run AutoGetIt, check "Installed Only" then "Refresh Package List", then select "Uninstall checked" in AutoGetIt; optionally saved checked list. Disable/Remove IDE Plug-ins: Start Delphi and using GExperts Expert Manager, disable all experts, including GExperts itself. Remove Third-party Components: Select Component > Install Packages from the Delphi menu and remove all third-party components. Backup FDConnections: make a copy of the FDConnectionDefs.ini in my "public docs"\Embarcadero\Studio\FireDAC folder. Run the installer, keeping defaults. After the installer is finished, there are similar steps to get my system set up again: Check the Path: If the Path environment variable is getting too long, create short path substitutions and replace their entries. Restore FDConnections: restore the copied FDConnectionDefs.ini. Reinstall Third-Party Components Re-Enable/Reinstall Experts: A lot of times, I find the previously disabled experts to be re-enabled and working but might have to reinstall some. Reinstall GetIt Packages: If AutoGetIt is still running, simply hit "Install Checked" otherwise, load the saved items then install them all. Re-enable User Access Notifications: Do not forget to keep your system protected against unauthorized installs!

This will be a good starting point: https://docwiki.embarcadero.com/RADStudio/Athens/en/Migrating_BDE_Applications_to_FireDAC I'm working on a team, migrating several dozen Delphi apps using the BDE to FireDAC and found the reFind utility to help a lot; it even has templates for the BDE-to-FireDAC migration to get you started. I expanded the template a lot to deal with several other facets of our internal migration needs.

It works with Indy. In programs I have distributed, I give the user the choice of using FTP or SFTP; the FTP is handled with Indy, SFTP with SecureBridge. You can use it independently but SecureBridge does have an "IOHandler" for providing integration with Indy components, both versions 9 and 10. I have only used it with Windows so cannot speak from experience but their products and support are good and I would expect they are fully supported. From their help manual: From their help manual: I do not have to ship OpenSSL libraries or DLLs with programs I distribute. If there's an update to SSL and clients require newer security protocols, I simply update my SecureBridge components, rebuild the project, and send it out. If I build with packages, I need to include one additional BPL, sbridge290.bpl (for Delphi 12). If you have more detailed questions, they have good support and are happy to answer pre-sales questions. I've been a Devart customer for many years, having used several of their xxxDAC products.

I've been using SecureBridge from Devart for years--works well.

Yes, you're right. Good point.

You're right--sorry; still, like PeterBelow said, it's not a user-triggered change.

In that case, it's reasonable to expect it will only be called once. What I see a lot of people do to make certain code is only called once is to set a boolean flag to False in OnCreate, then in OnActivate, check that flag, and if false, set it to true and do your one-time code. That way, even if some future part of your program decides to hide the form, you won't have to worry that your code is executed more than once. As far as I know, no. Correct.

The documentation for TComboBox.OnChange has this note: I'd extract the case statement from ComboBox1_Change to a separate procedure and call the new procedure from both ComboBox1_Change and Panel1_Click.

Not necessarily. If you hide the form, then show it again later, the OnShow event will get fired again. Basically, calling Show or ShowModal when the form is hidden or manually toggling the Visible property (which is what Show and Hide do) will trigger the OnShow event. Attached is a sample project to demonstrate. OnShowTest.zip

You won't find anything about dark mode when managing platforms, you control Dark Mode under Tools > Options > User Interface > Theme Manager. But if you have a corrupted .ISO, perhaps download it again to see if you can get a better copy; also compare the MD5 hash to make sure it's not corrupted once it's downloaded. Or, just use the web installer instead (if that's practical for your case).

Does "rewriting" include changing the database or SQL? Or are you simply upgrading to a newer version of Delphi? @Dmitry Arefiev is correct that the problem is that "AUTO_CORRECT" is not a recognized keyword in Interbase. @Lars Fosdal is also correct that it can be emulated. My point is that your problem is not with Delphi, it's with the SQL, which leads me to question what all you're doing in the rewrite.

Not sure who you're asking. Skrim didn't say he was using shortstring. I put that in the first example as a way to generate the error he saw--but no, I never use them in new code. When I use MyField.Value (as in my second reply), the warning lists "AnsiString" instead of "ShortString" which is what led me to write what I did in the first suggestion, not knowing what code he was dealing with.

Yeah, lots of hidden gems have been added over the years. I don't always read everything in the "What's New" section and also occasionally discover features that have been there for a while! It wouldn't be the underlying database structure but how they're accessed. I often get this type of warning when upgrading old applications (Delphi 5/7/2007) to newer versions where string fields were assigned like this: procedure UpdateValues(const NewValue: string); begin MyTable.StrField.Value := NewValue; ... The .Value property is AnsiString; simply changing it to use the explicit type eliminates the warning: procedure UpdateValues(const NewValue: string); begin MyTable.StrField.AsString := NewValue; ...

If you hit F1 on the warning, you'll get the following explanation: For example: var s: string; code: string[3]; begin ... code := s; ... Here, code is declared to be exactly 3 characters and known as ShortString; but s is declared as the default string type, Unicode. If s happens to contain 4 or more characters or happens to contain multi-byte characters, the assignment will lose data. The compiler is warning you about this possibility. Yes, you can turn off this warning (in Project Options > Delphi Compiler > Hints and Warnings) but I would not recommend it as unforeseen bugs can more easily creep into your code. The except might be temporarily considered when inheriting an old project that has been working for years and compiling generates thousands of hints and warnings and you just want to turn down the noise until you can get the project under control.

To me, "stand alone" means it's not a plug-in for something else. So, yeah, could be large or small. Thanks for the clarification. :-)

SQLite's own documentation lists some reasons why using it might not be the best for every situation. That's a pretty broad question and could mean anything from a small single-person app with a few records in a couple of tables (where SQLite would be perfect) to a large, multi-user application suite with hundreds of users over a large network with thousands of transactions per minute (where SQLite would be quite inadequate).

I just want to share my similar setup (but with no problems): I also remotely access a physical Windows 11 machine via VPN/RDP. I upgraded from Delphi 12.1 to 12.2 a couple of weeks ago and have no problems with blinking. The only thing different is that in order to keep my main computer's internet connection for Teams meetings and personal email, I start up a VMWare machine and connect remotely from there. The VMWare machine is running Windows 10. So basically, it's like this: Windows 11 desktop (three monitors): VMWare virtual machine with Windows 10 on two of the monitors VPN/RDP -> Windows 11 with Delphi 12.2 Fast internet, fairly new hardware on both ends, all visual options on in RDP, works great.