Re: gnat ada DLL and VB

["David Botton" <David@Botton.com>]

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.