Re: SetConsoleCtrlHandler called when accessing ODBC/OLEDB datasource

> Also how about to load BANTAM.DLL explicitly,
> before establishing yours handler to Console events?

Here is how I solved my problem:

I used TADOConnection.OnAfterConnect to start a TTimer which one second
later restore my own CtrlHandler. I had to use a TTimer because AfterConnect
is triggered just before BANTAM.DLL set his own driver. One second delay is
enough to reinstall my CtrlHandler and small enough to have almost no chance
for the user to close the application in the meantime. This has to be done
only once, when the first connection occurs.

--
francois.piette@xxxxxxxxxxx
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be



"Vitali Kalinin" <vitkalinin@xxxxxxxxx> a écrit dans le message de
news:42de3bca@xxxxxxxxxxxxxxxxxxxxxxxxx
> "Francois Piette [ICS & Midware]" <francois.piette@xxxxxxxxxxx>
> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
> news:42de2fb6$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > How about to switch to native OleDB provider for DBF file
> >
> > No problem as long as it works.
> > It has to talk to dBase IV data _and_ index file (mdx).
> As for dBase IV it should work as for _and_ index file (mdx) I am not
sure.
>
> > > (I believe FoxPro have one)?
> > > Jet OleDB provider also could talk to DBF files.
> >
> > As far as I know, Jet engine is only able to read simple DBF (no index)
> > file.
> > And foxpro has a different index type.
> >
> > Note that I configurer the data source using Microsoft diver for dbf and
> > this driver use Borland code thru ODBCJT32.dll which is Microsoft
driver.
>
> So it looks like changing to other OLEDB provider from Microsoft won't
> change faulty behavior, but still worth to try. Also how about to load
> BANTAM.DLL explicitly, before establishing yours handler to Console
events?
>
>


.