Using the databes throu a server

I have a program that uses a database using ADO and DAO components. and now I need to put the database files on a server and make a client program that uses the database from another computer on the local network. how do I call the database files and manipulate it (probably using SQL I imagine?) without changing too much of my current program.
(please provide examples)

With ADO you shouldn't need to do much. If you are using a DSN, just change the DSN to point to a different database. Your application shouldn't know the difference.

I don't know about DAO.

a question... why are you using ADO AND DAO? It would seem that ADO would be enough to cover DAO (considering that it is it's replacement)

Different between ADO and DAO:
Each of these are data access interfaces--mechanisms for programmers to
access data stored in a database.
DAO is designed to access JET/Access databases (only). It includes a great
deal of flexibility to deal with DDL/DML issues and manage the database
schema.

ODBC is an API interface designed to access any relational database that
supports an ODBC driver. DAO uses ODBC behind the scenes to access
relational databases (albeit not very efficiently).

ADO (COM-based "classic") is a VB-accessible route to the OLE DB data access
interface which uses "providers" (like ODBC drivers) to access data in
relational and non-relational databases. ADO is generally accepted as the
defacto standard way to access data from VB, C++ and Office applications.
ADO's biggest problem is COM and DLL hell issues.

ADO.NET is an entirely new data access interface built into the .NET
Framework. It bears little resemblance to ADO classic. It is COM-less and
shares none of the DLL hell issues with it's predecessor.

DAO and ADO are both client-side "data consumer" object
classes while ODBC is a standard for "data providers".

You use either DAO or ADO with ODBC. DAO is supposed to
be optimized for ODBC while ADO is optimized to OLD DB,
which is another data provider. (I'm pretty sure you can
use DAO with OLE DB as well.)

DAO is a predecessor to ADO - ODBC is a predecessor to
OLE DB.

Microsoft recommends ADO/OLE DB for new development but
that converting DAO code to ADO may not be worthwhile in
terms of performance improvement, etc.

exactly my point, CP - if you're writing a new project, then I don't see any reason to use both ADO and DAO, as ADO can handle the processing just fine. However, on older projects which are being revised, I can understand leaving DAO alone.

Yes,I am agreed to FisherMan!

Your about right. I have this program for employee's to check in and out of so their work time could be calculated. But I need to change it now so that the database will be located on a server and every employee would check in on their terminal and the program will change the database on the server.
This program contains both ADO and DAO. I left the old DAO because I dont know how to change it to ADO (the dao is created not using components, but with code. And the syntax for ADO is defferent). But I dont know much about DSN and I dont know **** about server related database.

please help me

Honestly, Tom, my advice would be to do this.

1. Get rid of DSN's. I never use them. I know they make things simpler as far as updating a central piece of information, but I don't like them. The closest I ever come to a DSN is by declaring a [DATABASE] section in an .ini file I include with my build, and then putting a line in there declaring DSN="SomeMachine", but I don't even do that often.

While you're at it, I would switch to SSPI (secured, integrated access using Windows Authentication). It's a simple switch in your connection string, and it get rid of any hard coded usernames and passwords.

2. Take a little time, and try to find out what the DAO Code is accomplishing. You can probably examine any query statements and get a good idea. Once you know what is required.. I would seriously consider switching it to ADO.

3. This is more of a question... what kind of DBMS are you using. Is it Oracle, SQLServer... or what? There could be some other things you could do to streamline and even out processing distribution.

Right know Im not using any of these (in replye to point 3), but Ill probably use SQL for the DBMS.