🚀 go-pugleaf

"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