Lars Fosdal

We've found that date conversion problems often stem from Windows 10 using the same separator for time and date.

Did the inherited destructor remember to call inherited?

Should prolly do a status summary on the issues of this thread and start a new one, but don't have time right now.

You can write apps for Win 7 if you take care, but the Delphi IDE itself does NOT support Windows 7.

Undeclared types probably do not have RTTI because it kinda pointless to be looking up an unnamed type using RTTI, since you don't have a name to look up. Besides, if you were using unnamed types in a class in production code, I'd fire you from my team.

@Stefan Glienke I concur.

Check registry HKEY_CURRENT_USER\Software\Parnassus OU\Core Is the value of Path set to C:\Program Files (x86)\Common Files\ParnassusShared ? - if not, make it so. Copy the 20.0 DLLs there as per earlier posts.

"faster code with managed records" - faster in what way?

10.4 does not overwrite the 10.3 versions in C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ So, First install for 10.3, then install for 10.4 - and apply the fix above.

10.4 has an update to Bookmarks and Navigator. It creates C:\Program Files (x86)\Common Files\ParnassusShared and places ParnassusBookmarks_XSydney.dll ParnassusCoreEditor_XSydney.dll ParnassusNavigator_XSydney.dll So, to cure the 10.3 ailments, copy from C:\Users\<username>\Documents\Embarcadero\Studio\20.0\CatalogRepository\ to the first mentioned common catalog Bookmarks-1.0\ParnassusBookmarks.dll to ParnassusBookmarks_XRio.dll ParnassusCoreEditor-1.0\ParnassusCoreEditor.dll to ParnassusCoreEditor_XRio.dll Navigator-1.0\ParnassusNavigator.dll to ParnassusNavigator_XRio.dll

I can't believe they fucked it up again...

Have you tried TCamRemote from https://alkenius.no-ip.org/

It just dawned on me that you wrote the Monitor didn't produce any logging for that query. That strongly suggests that it fails in the preprocessing. What type are the parameters, and can there be invalid data passed to the query? Garbage strings, NaNs, invalid pointers, etc?

SQL Server has pretty good diagnostics and logging, so if a query causes it to hang, it should be detectable. I would suggest trying a minimal example with the explicit query through FireDAC, and compare that with the parameterized query. Check parameter by parameter that the value type is correct. That the format is correct (number, date, etc).

I wonder why TChart is not a GetIt thing?

Do you get an error if you allow it to time out when it hangs? When SQL just hangs, the cause can be a deadlock. That means that the table you are trying to update, is busy somehow. The default timeout is typically 30 seconds before a thread is declared the winner and the other threads accessing the table gets a lock error and have to do a retry. This is the reason we in our team do our MSSQL table updates through stored procedures. That allows the procedure to do a try/catch and retry if it fails due to a deadlock. Preventing deadlocks: It is important to avoid "lingering" cursors to reduce the risk of deadlocks. F.x. If you really need a cursor, do a select into a memory temp table, and create the cursor on that temp table. If a complex select or view can safely use "With NoLock" on a table, use it.

Ah, my bad - I didn't notice the MMX context.

In the declaration? I usually end up with a recorded macro since I only rarely want a setter procedure.

Treat console apps like you treat VCL or FMX apps. Keep the actual code in units and have just the skeleton init and run code in the .dpr.

I tested in 10.3.3.

@Scott - Are you on subscription? In that case you can actually join the Beta testing pool and help unearth these problems. My team usually don't move to a new version until Update 1 is out.

Heated discussions that end well - No problem, IMO. Discussing in writing is always difficult. Differences such as cultural background and language can make it easy to trip up and come across the wrong way. As long as we are patient and try to stay positive and on the ball instead of the man - there is hope.

You're asking for immutability ... this is hard to achieve on unmanaged system and specially for Delphi (breaking type-system compatibility). I think placing constants on ROM would be much better as it doesn't require changing the system-type language. What do you think ? I think that I really don't care about the underlying implementation detail. I just want truly constant typed constants. It would allow me to write consistent, readable, reusable code and allow array parameters and typed constant parameters for attributes. A minor performance penalty would be acceptable if that goal could be achieved.

Dude, why do you think I wrote And again - I really don't care about the speed penalty. I just want constants that are actual constants also when typed and that cannot be changed at runtime.

Cut'n paste and RX replace. That said: It is unlikely that I'd have more than a few thousand typed record constants. I.e. The increase in compiler time is for all practical purposes insignificant.