Subj: Access violation when using multiple sessions to different databases

Hi!


We are currently using ElevateDB 2.17 in one of our applications with C++ Builder XE5. It has two separate databases with completely different needs: one is a language db with translated strings for the UI, the other is used to track geographical positions. To facilitate this we have created two data modules with the following components:

Lang_Dm:
 * dbEngine:   TEDBEngine with default settings except for UseLocalSessionEngineSettings, which is enabled.
 * dbStrings:  TEDBDatabase with the database named 'Language' and the internal DatabaseName set to 'LangDB'. It has'LangSession' in the SessionName property.
 * dbSession:  TEDBSession with name 'LangSession'. All properties are default
 * tblStrings: A simple table with an Id and some translated strings, DatabaseName is 'LangDB' and SessionName is 'LangSession'.

When the data module is initialized we set dbSession->LocalConfigPath to a directory (eg: c:\temp\langdb) and dbSession->LocalTempTablesPath to the user's %temp% dir.

After that we check if the database actually exists with the following code:

TEDBQuery *  qry = new TEDBQuery(NULL);

try
{
   qry->DatabaseName = "Configuration";
   qry->SessionName  = dbSession->SessionName;
   qry->SQL->Text = "SELECT * FROM Databases WHERE name = 'Language'";

   qry->ExecSQL();

   ret = qry->RecordCount > 0;

}
__finally
{
   delete qry;
}

When this succeeds we set dbStrings->Connected to true, do a similar query to check if the table exists (SELECT * FROM Information.Tables WHERE name = 'TargetPositions') and finally set tblStrings->Active to true. All this seems to work without issues.

However, we also have a second database, which might complicate matters a bit. The tracking db uses a similar data module (with an engine, a separate session, a database object and a data table). The session points to a different LocalConfigPath and the temp path is also the user's %temp% dir. There is also a script that creates the database if it doens't exists.
Again, everything seemed to work fine in runtime...

... up until we discovered a mysterious access violation when applying a new configuration (a user might change the language, causing the language db to be re-loaded). Using the AQTime profiler's allocation profiler we discovered that in our "CheckTableExists" method data was writing outside of a memory block. After investigation, the error happens in the ExecSQL() method. What confuses us is that the error happens on CheckTableExists, but not on CheckDBExists, which uses the exact same code except for the SQL statement.

All the initialization steps are done on the main thread and called sequentially.

I suppose we are doing something wrong with the configuration, but we can't figure out what

Patrick


I haven't studied your post in great detail so I could be wrong about what you're doing. It looks as though you are trying to have two engine components in the one application and that is just not possible. This could be your problem.

Roy Lambert

Hi Roy,

We've removed the second DBEngine and now only have one engine component (in the Language data module), but the error still persists. According to AQTime it manifests itself when System::FreeMem is called somewhere.

Patrick


I don't use either AQTime or C++ so I'm not going to  be able to help much.

Can you post fuller code to give C++ programmers a chance? As you've guessed the probability is that you're doing something wrong somewhere but without code its very difficult to say what.

If you can post a demo app (source) that would be even better.


Roy Lambert

On 3/11/2015 5:18 AM, Patrick Speleman wrote:
> .. up until we discovered a mysterious access violation when applying a new configuration (a user might change the language, causing the language db to be re-loaded). Using the AQTime profiler's allocation profiler we discovered that in our "CheckTableExists" method data was writing outside of a memory block. After investigation, the error happens in the ExecSQL() method. What confuses us is that the error happens on CheckTableExists, but not on CheckDBExists, which uses the exact same code except for the SQL statement.
> All the initialization steps are done on the main thread and called sequentially.
> I suppose we are doing something wrong with the configuration, but we can't figure out what

Patrick,

How are your sessions named ? More specifically are you using the
AutoSessionName set to true or are you manually setting the name.

I did a quick read thru of your post and everything looks OK on surface.

My only suggestion is to check things as you would for multi-threaded
(http://www.elevatesoft.com/manual?action=viewtopic&id=edb2&product=rscppwin32&version=XE5&topic=Multi_Threaded_Applications)
- i do realize this is single (main) app but rules i think remain same
in your case since due to 2 separate configs/sessions/databases etc.

Otherwise these are peer supported forums so i would also suggest you
email elevate official support as well for quicker response.

Raul

Raul wrote:

>  More specifically are you using the AutoSessionName set to true or
> are you manually setting the name.

That is indeed the primary thing, which I cannot remember if it is a
default or not. It is important that the components on the module all
refer to that session, for each thread/ caller.

--

Matthew Jones

Matthew


Dunno about C++ but for Delphi its false. I generally don't use it and I'd notice if when I need a quick test bed I had to unset it (but I also cheated and had a quick look by dropping a session onto a form).


Roy Lambert

We're currently using manually set session names, not automatically generated names.
I've been trying to reproduce the issue in a small demo app but haven't had any luck yet (our main app is rather ancient and it isn't inconceivable that some arcane interaction between components is at the root of the problem). If I figure out what's going on I'll post it here.

Raul

>How are your sessions named ? More specifically are you using the
>AutoSessionName set to true or are you manually setting the name.

I don't think that really matters. If you try and use the same name in the IDE you get an error, haven't tried at run time but probably the same. If you get the names applied to the database wrong then it just won't open.

Roy

Patrick

>We're currently using manually set session names, not automatically generated names.
>I've been trying to reproduce the issue in a small demo app but haven't had any luck yet (our main app is rather ancient and it isn't inconceivable that some arcane interaction between components is at the root of the problem). If I figure out what's going on I'll post it here.

Sounds highly probable. Had a few of those spent many "happy" hours removing components one by one to find out what's causing it.

I know this is a teaching granny to suck eggs comment but have you put a breakpoint at the start of the function where you think the AV is and just stepped through? Errors can be reported in such a way that they seem to be coming from somewhere entirely different.

Roy Lambert