Hi - please download this small C# app (.NET 4.6.1) which demonstrates the problem :-

https://pioneersoftware.co.uk/files/temp/EDBUtil.7z

Since updating from 227b1 to 228b5, I noticed that my app was no longer closing down correctly - the process gets stuck and is still visible in Task Manager, even though the main form has been closed.

I tracked the problem down to EDB and have reproduced it in this simple demo app. To reproduce :-

[1] Simply run the program, then CLOSE it - notice that it closes normally; now...

[2a] Run the program, enter the connection settings to connect to a EDBSRVR server (running anywhere) and click CONNECT to establish the connection.
[2b] Now try to CLOSE the program and notice that the main window closes, but the process gets stuck in the Task Manager

This doesn't happen with 227b1 - the problem only manifests with 228b5.

Am I doing something wrong or is this a bug in the EDB ADO.NET provider?

Many thanks,

Hedley

Hedley,

<< Since updating from 227b1 to 228b5, I noticed that my app was no longer closing down correctly - the process gets stuck and is still visible in Task Manager, even though the main form has been closed. >>

It's a bug - the global I/O buffering is creating a threaded timer when it shouldn't for use in an assembly.   The threaded timers don't work correctly when used in a DLL (cannot synch threads from DLLMain issue in Windows), and the IsLibrary global variable isn't set correctly in Delphi when the code is in an assembly, so the timer thread is created when it shouldn't be.

I'll have a fix out in the next few days.

Tim Young
Elevate Software
www.elevatesoft.com

Ahhhh Ha!  And I thought I was imagining things when my Apps were still being 'held' by windows, even though the app
had been closed.

Ian,

<< Ahhhh Ha!  And I thought I was imagining things when my Apps were still being 'held' by windows, even though the app had been closed. >>

This only applies to the .NET data provider, not ElevateDB in general.  The .NET data provider is an assembly (.dll), and DLLs have special restrictions on what you can do from the main procedure, including certain things with threads.  Delphi has an IsLibrary global variable that was being used to check for this, but the Delphi .NET compiler did not set this variable for assemblies, hence the bug on our part. I should have checked this (technically, an assembly is not *exactly* the same thing as a .DLL), but just didn't think to do so.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,
   Ahhh Bummer!  Back to square one.
Ian