<P>Although there is nothing special about using ADO with ALP there are some recommendations depending on
the application deployment scenario and functionality required.
</P>
<P>Today ADO and corresponding OLEDB providers for Jet (at least) are installed by default on most of the
Windows machines. Even on older OS versions like Windows 95 these component are present almost always - 
installed by other software. But which version? You can assume that your application has chance to find
at least Jet 3.5 on over 95% of the Windows PCs. ADO version will vary from 1.5 to 2.6. Of course you
may choose to compose installation that will update the MS Database Access Components on the system, but
depending on your aims you may want to avoid this if possible. You can see also the <B>Testing the PC</B> 
section for samples on how to check the host OS for the components often used in the ASP applications.
</P>
<P>So, you may want to be prepared and develop your database code with minimum requirements in mind. 
For example if you want to distribute your application on autorun CD it will be a great advantage for it
if system update is never needed. One of the possible ways is the usage of the features supplied by ALP 
and its components (like ActiveX Pack1). You can design an application that uses data files in custom manner 
and avoid DB usage. However the mentioned components do not offer full DB functionality - only partial 
similarity and their major purpose lies elsewhere. So, DB usage cannot be avoided always and even if it is possible 
you may need to spend too much efforts. In such cases you will probably decide to use ADO and use only features
that are available on all the popular versions of ADO and Jet engine (that drives the MDB files).
</P>
<P>This means the following - limiting the ADO features used to those that exist in version 1.5, use MDB files
for MS Access 97 or earlier (for Jet 3.5) and use Connection strings based on ODBC in order to avoid problems
with the versions of the native OLEDB providers for Jet. An example for such string:<BR>
<B>Driver={Microsoft Access Driver (*.mdb)};DBQ=C:\file.mdb;</B><BR>
Of couurse the file name should be composed using the Server.MapPath method in order to make the application
location independent. As for the ADO features most important ones are present, as for the extended features such 
as ADO stream and so on you can use the alternative objects from ActiveX Pack1 that ships with ALP - they are even
much more powerful than those implemented by ADO. The MDB file - there is considerable difference between the
MDB files supported by the newere versions of the Jet engine (4.0 or later) and the earlier versions. The most 
important difference is that the earlier MDB files use ANSI strings instead of UNICODE. However this lowers their 
size. So to achieve these targets you will need to use the <I>convert to old version ...</I> function in the 
Access 2000 and later.
</P>
<P>Applications developed for certain clients, applications that will require installation procedure by design
may can be developed without these limitations. If a setup will be performed there is no reason to limit the 
application functionality if you can redistribute the components you need with your application.
</P>
<P><B>Conclusion:</B> Depending on your application purpose you may need to consider its dependencies and try
to use functionality that will lower the need of additional components redistributted with it. This is problem
for any desktop oriented development technique and is not specific to ALP, however we know that WEB developers
are used to servers they are aable to update as need. So, we want to emphasize that the ASP applications for ALP
are desktop applications and developer must be aware of its application requirements. ALP is open environment and
you are able to use thousands of ActiveX components with it. However if you want to simplify the application 
deployment you will need to pay attention to their number and specifics and, if possible, limit them to the vital
minimum. A good planning will allow your application to work everywhere and at the other hand greater requirements
will cause your clients to install additional software, download huge archives and so on. We have a huge experience
in this area and we will always help our customers to find the perfect way. We encorage you to ask us 
in the beginning and not after the application is finished.
</P>
