I came across a strange error that's not in the manual: "ElevateDB Error #408 The ElevateDB engine cannot be open when performing this operation (MODIFY ENGINE)".

Anyone seen this before?  I'm not actually doing anything with TEDBEngine so it may be a red herring.

= Steve

Steve,

What version are you using and under what circumstances does it happen?

--
Fernando Dias
[Team Elevate]

Hi Fernando,

<< What version are you using and under what circumstances does it happen? >>

I think it's probably due to some issues I'm having with threading some database connections.  The database objects are created and destroyed dynamically by a class, which is created and destroyed dynamically within a thread.  The database objects are completely isolated from the main thread.  It seems the error might be a result of "stream signature was not received" errors I'm also getting.

Thanks for responding.  I am now talking about it with Tim via email, however if you have used threading with EDB I'd be grateful for any insights or tips you may have.

= Steve

RAD Studio 10.2.3
ElevateDB 2.31 Build 3

Steve


I used threads from DBISAM onwards, creating components in the thread, having classes created in the thread and in turn creating ElevateDB components, passed the session around when a wadge of stuff was all running in the same thread, single threads, multiple threads.

No tips apart from following the rules and, unfortunately for you but fortunately for me, no real problems, at least not for several decades and not since the switch from DBISAM to ElevateDB.

Roy Lambert

<< I used threads from DBISAM onwards, creating components in the thread, having classes created in the thread and in turn creating ElevateDB components, passed the session around when a wadge of stuff was all running in the same thread, single threads, multiple threads.

No tips apart from following the rules and, unfortunately for you but fortunately for me, no real problems, at least not for several decades and not since the switch from DBISAM to ElevateDB. >>

Thanks Roy.  What makes it worse is the problem changes where it occurs, ie. it will occur in one method, and next time that method will work fine and it will occur in a different method.  Weird stuff.

= Steve

On 5/21/2019 6:27 PM, Steve Gill wrote:
> Thanks Roy.  What makes it worse is the problem changes where it occurs, ie. it will occur in one method, and next time that method will work fine and it will occur in a different method.  Weird stuff.

That is good indication it's a threading issue - memory layout and how
threads exactly run varies each time so problem appears to "move" as well.

If you have any code you can extract and show we could try to help

You mentioned you have isolation already so i would look at either
something that uses default objects (since you did not assign ones) or
passing objects around and accessing across threads

Raul

Steve

><< I used threads from DBISAM onwards, creating components in the thread, having classes created in the thread and in turn creating ElevateDB components, passed the session around when a wadge of stuff was all running in the same thread, single threads, multiple threads.
>
>No tips apart from following the rules and, unfortunately for you but fortunately for me, no real problems, at least not for several decades and not since the switch from DBISAM to ElevateDB. >>
>
>Thanks Roy. What makes it worse is the problem changes where it occurs, ie. it will occur in one method, and next time that method will work fine and it will occur in a different method. Weird stuff.

Whilst its more likely to be in your code the problem I had in DBISAM decades (and I do mean decades) ago occurred in my homebrew mail, news & RSS (that shows how long go) client. I would kick off up to 4 threads to download, and every so often I'd get an error. It never happened with a single thread. It took a mass of time and effort before I managed to produce a test case that Tim could use to fix it.

As I say its more likely to be your code but you could be hitting an edge case in some unforeseen manner. In which case my sympathies and good luck.

Roy

Hi Roy,

<< Whilst its more likely to be in your code the problem I had in DBISAM decades (and I do mean decades) ago occurred in my homebrew mail, news & RSS (that shows how long go) client. I would kick off up to 4 threads to download, and every so often I'd get an error. It never happened with a single thread. It took a mass of time and effort before I managed to produce a test case that Tim could use to fix it. >>

I always assume it's my code, and I'm sure it probably is.  

I'm not actually using TThread.  

I started with TTask in the Delphi Parallel library.  When I got the errors I re-coded to it to use Async/Await from the OmniThread library.  I got the same errors.  I checked with Primož Gabrijel&#269;i&#269; (the author of OmniThread) to make sure I was using the library correctly.  He kindly confirmed I was.

I think I'm having a similar situation that you mentioned that you had with DBISAM when kicking off 4 threads.  It seems only to happen when more than one thread is started, and the thread where the error occurs varies.  

I added compiler directives so that I can turn off the threading.  When I turn off the threading I don't get the errors, so I know that it runs okay in the main thread.

<< As I say its more likely to be your code but you could be hitting an edge case in some unforeseen manner. In which case my sympathies and good luck.>>

Well that would be typical for me.  Thanks Roy.

= Steve

On 5/22/2019 6:29 PM, Steve Gill wrote:
> I started with TTask in the Delphi Parallel library.  When I got the errors I re-coded to it to use Async/Await from the OmniThread library.  I got the same errors.  I checked with Primož Gabrijel&#269;i&#269; (the author of OmniThread) to make sure I was using the library correctly.  He kindly confirmed I was.
>
> I think I'm having a similar situation that you mentioned that you had with DBISAM when kicking off 4 threads.  It seems only to happen when more than one thread is started, and the thread where the error occurs varies.
>
> I added compiler directives so that I can turn off the threading.  When I turn off the threading I don't get the errors, so I know that it runs okay in the main thread.
>

Why don't you show a simplified sample of what you're doing.

Multi-trheading in EDB is very straightforward. Make sure you have :
- unique session (with unique sessionname)
- unique database and connected to session above
- unique table and query connected to session and database above

Creating these in code is easiest since you can ensure it's all setup
properly.


Raul

Steve Gill wrote:

> I started with TTask in the Delphi Parallel library.  When I got the errors I re-coded to it to use Async/Await from the OmniThread library.  I got the same errors.

Hmm. I'd want to really know how that was being done. I fell over interesting issues in the RemObject RO-SDK library by trying to be clever. The key here is that a lot of systems use a "thread pool", which optimises resources. So your task might be run using threadA now, and threadB in a little while as it picks up again. Elevate and other databases need a session /per-thread/ so if you do anything clever like keeping the session in an object that the thread pool is working on, that session gets mixed around the threads. The only solution is actually simple: create a full session and everything for each operation you do. So your task starts by creating a new session, linking databases to it, doing the work, and then freeing it all up again. Sounds horrible, but it works reliably, and doesn't actually take a lot of time on modern kit. Don't keep sessions hanging around in thread pool based code.

If you are using full TThread based code, that stays around for a while, then it can have its own session and persist it forever, as no other thread will be touching it.

--

Matthew Jones