Re: gnat ada DLL and VB

["isaac buchwald" <isaac.buchwald@velenje.cx>]

 ado  - was used  as  fuss  (  old Will used to use the word  i presume).
 but to confess  ,  there was an allusion to ADO.

 But  the matter  of  DLL  ,  why  don't  you  simply  say :
  I can't  figure  it  out   how to do it,  and neither  anybody  i know.

   puningly yours,
                    isaac


"David Botton" <David@Botton.com> wrote in message
news:mailman.997883873.22464.comp.lang.ada@ada.eu.org...
> The best way to create portable libraries in general is to abstract the OS
> interface to the Ada code.
>
> When you are writing a COM object you don't have to use ADO or any COM
> objects with in your Ada code.
>
> BTW, there is no seperate layer in COM itself when used inproc (DLL base
COM
> object).
>
> As for layers in ADO (since you mentioned it), it depends on how you
> connect.
>
> ADO can do ADO/OLEDB -> ODBC -> Server  so you get an extra layer of ADO
on
> top of ODBC
>
> or you can go direct using ADO/OLEDB drivers to the server skipping ODBC
in
> the middle.
>
> In high volume datbase access on WinXX machines ODBC is a very poor option
> and has problems with multi tasking with most ODBC drivers. ADO (when
going
> direct with OLEDB drivers) does not suffer this and has better performance
> then ODBC in general.
>
> I know that some may disagree with me, but not using native toolkits (when
> they are the best tool for the job) on platforms is a sign of lazy
> programming and poor design. On Windows 9X/NT/2K/XP/CE, the shared library
> of choice is COM and the data access method is ADO/OLEDB. DLLs are second
> class citizens on Windows today. Sort of like .com instead of .exe :-)
>
> David Botton
>
>
> ----- Original Message -----
> From: "isaac buchwald" <isaac.buchwald@velenje.cx>
>
>
> >   but there is  one more reason , why  not  to use it.
> >
> >   If  i write  a  package in ada ,  i  would  like to  use   in a
> different
> > invironment
> >   without much ado , and without  a  separate layer  that  brings  in  a
> new
> >   peril  of   quer  functioning.
>
>