🚀 go-pugleaf

"Simon Elliott" <Simon at ctsn.co.uk> wrote in message 
news:45105819$1@newsgroups.borland.com...

> I've reduced the app to a small consolde mode test app, and still
> happens.

How small is the test app?  Is it small enough that you can post the code 
here?  Is it small enough that you can post it to the attachments newsgroup?

> Any thougths? What's the best way to go about tracking this down?

Whenever problems like this occur the best thing to do is either reduce code 
until the problem goes away or start from scratch and add code until the 
problem exhibits itself.

I can confirm that I have seen access violations that happen in release mode 
that do not happen in debug mode; however, it's not been specific to ADO. 
Does your code have any startup initializers that rely on other startup 
initializers?  Does your project rely on other packages or libraries that 
you have created or other third party packages or libraries?  Is your 
project a standalone EXE?

Hopefully I have asked enough questions to get this ball rolling.

- Clayton 

On 23/09/2006, Clayton Arends wrote:

> How small is the test app?  Is it small enough that you can post the
> code here?  Is it small enough that you can post it to the
> attachments newsgroup?

I've reduced it to a very small app: see below.
> 
> > Any thougths? What's the best way to go about tracking this down?
> 
> Whenever problems like this occur the best thing to do is either
> reduce code until the problem goes away or start from scratch and add
> code until the problem exhibits itself.
> 
> I can confirm that I have seen access violations that happen in
> release mode that do not happen in debug mode; however, it's not been
> specific to ADO.  Does your code have any startup initializers that
> rely on other startup initializers?  Does your project rely on other
> packages or libraries that you have created or other third party
> packages or libraries?  Is your project a standalone EXE?
> 
> Hopefully I have asked enough questions to get this ball rolling.

Yes, thanks for getting this started: I had just about run out of
ideas.

The code follows. It's just a very basic console mode app created by
the BCB6 console wizard. Works fine in debug mode and fails with a
memory overwrite exception in release mode.

//-------------------------------------------------------------------

#include <vcl.h>
#include <ADODB.hpp>
#include <DB.hpp>
#pragma hdrstop
//-------------------------------------------------------------------

#pragma argsused
int main(int argc, char* argv[])
{
  CoInitializeEx(NULL, COINIT_MULTITHREADED);
  AnsiString strDatabaseName =
"E:\\Work\\AntennaAudio\\Datalogger\\dev\\tmdb6X.mdb";

  AnsiString strConnectionString;
  AnsiString strSQL;
  Variant vCatalog;
  Variant vConnection;

  // Connection string. Use 4.0 to make an Access 2000 object
  strConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=";
  strConnectionString += strDatabaseName;

  // Create the database
  vCatalog=Variant::CreateObject("ADOX.Catalog");
  vCatalog.Exec(Function("Create") << strConnectionString);
  vConnection = vCatalog.Exec(PropertyGet("ActiveConnection"));
  vCatalog.Clear();

  // Create the tables
  strSQL = "CREATE TABLE tblTest (MyIndex COUNTER(1,1) NOT NULL
CONSTRAINT PrimKey PRIMARY KEY, MySerial INTEGER, MyShort SHORT,
MyTimen DATETIME, MyText TEXT(255), MyInteger INTEGER, MyByte BYTE)";
  vConnection.Exec(Function("Execute") << strSQL);

  // Close the database
  vConnection.Exec(Function("Close"));
  vConnection.Clear();

  CoUninitialize();
  return 0;
}

This will take some investigating to track down.  I see exactly what you are 
talking about.  However, one thing I'd like to mention is that this problem 
might have nothing to do with ADO.  Your code doesn't use the ADO classes 
(TADOConnection, etc) or the ADO COM objects (Adoint::_Connection, etc). 
Instead it uses what I will call the VB way of accessing COM objects through 
Variant.  I have no experience with this.  Though, from what I see it 
doesn't look like anything is wrong with your code.

- Clayton 

The only function that causes the AV in this test application is the 
"Create" function.  If I make no other changes to the application and simply 
wrap the Exec() call in a try..catch block then the app executes correctly. 
It even executes other code in the try area which means it's not throwing 
anything.  Example:

  // Create the database
  vCatalog=Variant::CreateObject("ADOX.Catalog");
  try
  {
    vCatalog.Exec(Function("Create") << strConnectionString);
    printf("1\n"); //<-- this prints
  }
  catch (...)
  {
    printf("ouch!\n"); //<-- does not print
    throw;
  }
  printf("2\n");

I don't believe this is the solution but it is interesting.  I'm going to 
perform some more searches in Google.

- Clayton 

On 23/09/2006, Clayton Arends wrote:

> The only function that causes the AV in this test application is the 
> "Create" function.  If I make no other changes to the application and
> simply wrap the Exec() call in a try..catch block then the app
> executes correctly.  It even executes other code in the try area
> which means it's not throwing anything.  Example:
> 
>   // Create the database
>   vCatalog=Variant::CreateObject("ADOX.Catalog");
>   try
>   {
>     vCatalog.Exec(Function("Create") << strConnectionString);
>     printf("1\n"); //<-- this prints
>   }
>   catch (...)
>   {
>     printf("ouch!\n"); //<-- does not print
>     throw;
>   }
>   printf("2\n");
> 
> I don't believe this is the solution but it is interesting.  I'm
> going to perform some more searches in Google.

Thanks for looking into this. I agreee that this is not the solution,
but hopefully it's iterating toward a solution.

You mentioned in an earlier post that this is more a "VB" solution. I
was advised when starting out on this, that this was closer to the
underlying "bare metal" of the way that MS Windows handles ADO, and
therefore I'd experienece less problems and issues. Is this perhaps not
the case?

I wonder if my prerequistes for mulithreading
CoInitializeEx(NULL, COINIT_MULTITHREADED);
is incorrect. The app which ultimately uses all of this is heavily
multithreaded so I want to make sure that mulithreading support is
enabled.


-- 
Simon Elliott    http://www.ctsn.co.uk

"Simon Elliott" <Simon at ctsn.co.uk> wrote in message 
news:4515af1d@newsgroups.borland.com...

> Thanks for looking into this. I agreee that this is not the solution,
> but hopefully it's iterating toward a solution.

I was only able to find one post that demonstrates similar behavior.  I 
searched Google for "cppbuilder variant exec debug av" and this is the link 
(one line, of course):

  http://groups.google.com/group/borland.public.cppbuilder.activex/
  msg/6252a8bcadff64c4?dmode=source

> You mentioned in an earlier post that this is more a "VB" solution. I
> was advised when starting out on this, that this was closer to the
> underlying "bare metal" of the way that MS Windows handles ADO, and
> therefore I'd experienece less problems and issues. Is this perhaps not
> the case?

I don't know if it's more/less optimal than using the VCL classes found in 
ADODB or using the COM classes in ADOINT.  I'm sure there are some hidden 
features that are much easier to get at using the technique you are using. 
The "VB way" is definitely more flexible since you can access any OLE/COM 
interface without making a class or importing a DLL or other LIB and header. 
However, I doubt that you will be able to use TDataSource or the other DB 
components/controls through this Variant interface (I'm prepared to eat 
those words if someone else can contradict me).  If this is not a 
requirement for you then this won't be an issue.

I'm afraid that at this point my information on this problem is maxed out 
and with it my ability to help "fix" it.  For now you may have to leave your 
app in "debug" mode.  I have one released product that we had to do that. 
There was no time to hunt for the cause of an infrequent error we were 
experiencing in debug mode.  Fortunately, this only adds about 2K to the 
application so is not really a big deal.

Perhaps you can contact Wayne Smith and ask him if he was ever successful in 
finding his problem.

- Clayton 

On 23/09/2006, Clayton Arends wrote:

> 
> I don't know if it's more/less optimal than using the VCL classes
> found in ADODB or using the COM classes in ADOINT.  I'm sure there
> are some hidden features that are much easier to get at using the
> technique you are using.  The "VB way" is definitely more flexible
> since you can access any OLE/COM interface without making a class or
> importing a DLL or other LIB and header.  However, I doubt that you
> will be able to use TDataSource or the other DB components/controls
> through this Variant interface (I'm prepared to eat those words if
> someone else can contradict me).  If this is not a requirement for
> you then this won't be an issue.
> 
> I'm afraid that at this point my information on this problem is maxed
> out and with it my ability to help "fix" it.  For now you may have to
> leave your app in "debug" mode.  I have one released product that we
> had to do that.  There was no time to hunt for the cause of an
> infrequent error we were experiencing in debug mode.  Fortunately,
> this only adds about 2K to the application so is not really a big
> deal.
> 
> Perhaps you can contact Wayne Smith and ask him if he was ever
> successful in finding his problem.

That might be the way forward. Thanks for your help. 

-- 
Simon Elliott    http://www.ctsn.co.uk