Roger Cigol

Closing a query does not close the corresponding database connection (this applies both if it is pooled connection or not pooled)

It's called the April patch - but it's out now ! https://blogs.embarcadero.com/rad-studio-12-3-april-patch-available/

Hi @MrBlues I do wonder if you might have been better posting your question as a brand new topic rather than adding it on the end of a year old and only partially related post. Not to worry.... It is always better to start with a *.xsd schema file rather than an *.xml data file when creating transformations. The schema can (and usually does) contain more information about fields. However not every use case allows this (a schema may not exist or may not be available) and XML mapper is designed to work when you start with an XML data file (as you have done) The main purpose of XML mapper is as a design tool. You create a dataset mapping and from this you create a transform file *.xtr, The normal case is then to forget about XML mapper and just take your transform file and use this at run time in your Delphi (or C++) application. If you load the transform file back into XML mapper it does not contain any data and you get the blank fields (exactly as you have described). There are (rare?) cases where you want to load in the *.xtr transform file back into XML mapper (perhaps if you want to edit it, for example). To do this you need to store a copy of the original XML data file in with the transform file, at the time the transform file was created. This usually results in a much larger transform file and this "file size bloat" serves no purpose when the transform is used at run time in a Delphi or C++ app. For this reason XML mapper now has a check box that must be selected (before the transform file is created) that forces XML mapper to include the XML data file in the transform file. You can see this check box (called "Incl. XML Schema" on your first screen shot, towards the bottom left of the middle section of XML mapper. BACKGROUND: Earlier versions of XML mapper did not have this check box and always added the XML data to the transform file.

All good ! There is more than one way to skin a cat.....

Of course there ARE times when the use of ANSI strings makes sense. One example is when sending data to/from an external device down an RS232 port where the external device uses a protocol based on simple ANSI text. We have many real world cases such as this (eg Eurotherm temperature controllers). The key point that @David Heffernan makes is that you should choose your types carefully to closely (or exactly!) reflect your needs. Time spent thinking carefully about your type selection will save you time in the long run.....

@GabrielMoraru Sorry to disappoint: I do very little Android programming. I think for mobile devices error reporting by a separate message box would not fit a user interface very well. Every time I try and do anything useful (with other firm's/organisation's apps) on a handheld device I think "well the designer of the software didn't do a bad job but everything would be easier on my desk top". Then I get back to base and do the same actions on my desktop and guess what? everything is so much easier !

It is recommended to use the same installer system (ie iso or web) as you used for your 12.2 installation

It's good to know April Fools Day is not just a British thing !

My partner, Julie, is just back from Manhatten where here hotel room was on the 42nd floor. 🙂

Yes: one of the worst things about thread safe / non-safe issues is that they do not always show themselves. A ThreadSafety issue can remain unnoticed during all your development and then you send it off to your customer and it falls over immediately. It has happened to me. Any thread work needs very careful design so that such bugs (which are the hardest to find) are avoided in the first place.

We have successfully written a 64bit C++ Builder App that ran on a Windows 10 64 bit OS and talked to an MS Access database. But you need to use the microsoft 64bit access run time driver package. This cannot exist along side the MS Access program. So either you have to uninstall MS Access before installing the 64bit driver package or you run the 64 bit application in a virtual machine with the MS Access *.mdb and other files on a drive that the virtual machine can connect to.

Embarcadero have not dropped support for MS SQL Server. It's just not in "Professional". I think "Professional" has always been limited to local databases only. MS SQL Server would rarely be expected to use just for a local database.

I think you are being a little unrealistic here in terms of business costings.

I use PostgreSQL and all seems good to me.

And yes, the viewing of data at design time using a 64bit database does work with 12.3 (certainly with 64bit versions of postgreSQL which is what I work with). The 64bit IDE is a first step. Of course we would all like it to work perfectly and to have had it a year ago but at least this shows it is coming. I am very much in favour of Embarcadero releasing stuff with limited functionality but which works rather than trying to rush too much out too quickly and therefore it all being very buggy. They have gone down this route in the past but seem to have learnt that this puts customers off. They do now seem to be releasing smaller changes at a time but smaller changes that work. I think this is much better for us users.

It seems that Embarcadero are encouraging C++ (new tool chain) users to save source code as UTF-8 with BOM. Can anyone find an option in the IDE set up to force files to be saved in this format ?

Thanks @Uwe Raabe I knew it had to be somewhere - and I have now found both with the help of your hints!

It's great to be able to use 64bit PostgreSQL interface in the 64bit IDE - You can see the database contents at design time.

Side note: very much off topic: but I love sending postcards and still send about hundred to different friends each year as I travel around.

VCL - RAD Studio 12.2 C++ Classic Compiler I have a windows C++ (Classic compiler) VCL application that uses TDirectory::GetDirectories() and TDirectory::GetFiles() to get lists of files from the Windows OS file structure. These files are then opened for read or write using stl ofstream and ifstream along with >> and << operators. The same code has been in use on different instances of the application on different machines (including Win XP and Windows 7). I have a new instance where the operating system is Windows 10 LTSC version 10.0.19044 build 19044. I have not run it on this version of windows before. Problem; Directory and file lists, reading and writing work ok for a longish time (24 hours sometimes, 30 hours sometimes, 10 hours sometimes) and then the calls to TDirectory::GetDirectories() and TDirectory::GetFiles() both return empty lists. Writing to a log file (with a fixed file name) also stops working at this time. It's as if my application has been locked out of the file system somehow. At this point it is possible to use File Explorer to see that there still are files and directories present. It is possible to open the files by other applications. (some are plain text files and can be opened with notepad). The files are stored in a directory inside C:\Users\Public\Documents\ so should be available to all applications all of the time. I cannot offer a reproducible example - all my code works fine on my development machine (which is Windows 10 Pro build 19045.5371 22H2). This is true if I run it under the IDE debugger or as a free standing exe. I wonder if any of my fellow Delphi-Praxis colleagues might have any similar experiences or can offer some ideas of what I should try next ?

Many thanks to all who helped - learning about the sysintern functions (handle.exe was the life saver) etc much appreciated. Special thanks to @Kas Ob. @Remy Lebeau @Der schöne Günther @Lajos Juhász

POSITIVE RESULT Having got the error code 1450 and then, very helpfully, being pointed in the direction of the "handle.exe" utility on sysintern this got us to a much better position: we could run our software and use "handle" to confirm that something was generating this continuous stream of unwanted (and presumably unused) handles which was eventually reaching some kind of windows out of resources threshold. This enabled us to (temporarily) remove parts of our code that talk to different bits of hardware and then repeat the test to check for unwanted handle production. We found that it was calls to a commercial driver for a specialist PCIe card that is used by our system that was the cause of the problem. This comes from a large respected scientific corporation, who's products we have worked with for a good many years (previously without any problems). Even better news: As part of this commercial package comes a separate test utility that allows you to check that card and driver have been installed correctly. This, too, gives the same stream of unwanted handles. So we are now able to go back to designer/manufacturer of the card/driver and show them how to spot the problem, which exists just using their own software. Fingers crossed that they will come back with a fix quickly!

Why would this kind of problem mean that only my application is affected? When the problem happens it is still possible to read and write files to the directories using windows explorer (eg right click and create a new text file).

Auto run: If I look for coloured entries - which are the ones with "not verified"..... In Services I see one: Sense Windows Defender Advanced Threat Protection Service: Windows Defender Advanced Threat Protection service helps protect against advanced threats by monitoring and reporting security events that happen on the computer. (Not Verified) Microsoft Corporation C:\Program Files\Windows Defender Advanced Threat Protection\MsSense.exe Mon Feb 10 16:31:35 2025 In Drivers I see three: BthA2dp Microsoft Bluetooth A2dp driver: Bluetooth A2DP Driver (Not Verified) Microsoft Corporation C:\Windows\System32\drivers\BthA2dp.sys Sat Dec 7 09:07:47 2019 BthHFEnum Microsoft Bluetooth Hands-Free Profile driver: Bluetooth Hands-Free Audio and Call Control HID Enumerator (Not Verified) Microsoft Corporation C:\Windows\System32\drivers\bthhfenum.sys Sat Dec 7 09:07:47 2019 Adobe Type Manager File not found: atmfd.dll The first two are in subcategory: HKLM\System\CurrentControlSet\Services The last one is in subcategory: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Font drivers

Running SFC did not sound dumb to me (either at the time you posted it, or now). This was done at end of January, after we had done a full "check for updates" iteration round a few times (until it said "all up to date").