Your three questions can largely be answered in discussion of three technologies available to the VB4 developer. They are JET, RDO, and OLE. Let's discuss these one by one and address your questions as we go.

VB4 includes the latest version of the JET database engine (version 3.0 for VB4 32 bit).

JET can be used in several ways:

Essentially JET encapsulates the ODBC API when accessing an ODBC data source, and exposes it as the normal Data Access Objects (DAO) interface. Thus, you can create a Database object, based upon an ODBC data source, almost identically to an Access database:

  Dim dbAccess as Database
  Dim dbODBC as Database
  Set dbAccess = DBEngine.WorkSpaces(0).OpenDatabase
                                       (":\VB\BIBLIO.MDB")
  Set dbODBC = DBEngine.WorkSpaces(0).OpenDatabase
                                     ("",False,False,"ODBC;")

What you see above is the minimal amount of information to open an ODBC database. The ODBC layer will then prompt for datasource, database name, user information, and so on. You can open as many ODBC database connections in this way as you need (within JET's generous limits). This does not require any attachments through an Access database, or any form of Access database at all (it's also measurably quicker). You can use Passthrough queries, Stored procedures, views, and whatever your ODBC data source supports.

VB4 also gives you another database alternative called Remote Data Objects (RDO). RDO provides a thin object layer on top of the ODBC API. This means you can access any ODBC data source with an object layer which is similar (but syntactically different to) JET's Data Access Objects. An important distinction here is that you are talking virtually directly to ODBC - the JET engine is not used. In fact RDO exposes the handles and values you need to make ODBC calls effecting your Remote Data Objects directly. Again, you can use this technology to open Connections (the RDO equivalent of a DAO Database object) to a number of ODBC data sources, thus allowing you to access data on multiple servers at the same time.

The main problem with RDO is that it is not as widely supported (or understood) as DAO. Also it can only be used to hit ODBC data. Whereas JET's DAO can be used to hit a variety of data repositories. Apart from that it can give you very good performance.

The issue of Remote OLE is quite different from the two database technologies described above. It is not a way to access data so much as a way for different applications to communicate and provide resources and functionality to each other. The only difference between OLE and remote OLE is that with remote OLE the OLE server can reside on a separate computer accessible over a network. This is achieved using a thin redirector layer. This means you can centrally deploy OLE servers that provide key functionality to a variety of applications and/or users.

The major step forward with OLE introduced with VB4 is that it is now very simple to build and distribute OLE servers. Also, because the OLE servers are built in VB4, they can use any of the functionality available to VB4 itself - and provide the same directly to other VB4 applications. This includes using JET/DAO, RDO and custom controls. This means that you can separate your application not only into interface and database server, but you can include a middle layer implementing business rules and specific functionality providing an extra layer of abstraction between the user and the data. The remote functionality of Remote OLE simply means that you can divide these three portions across network resources as you think best. They might all reside on one machine, or be distributed amongst a number of networked machines. For more information on the three-tier client/server approach, check out the Microsoft development Roadmap (refer to Footnote below).

Because Remote OLE servers have access to the JET/DAO engine and the RDO engine they can be used to serve data to your application however you wish, as well as processing the data themselves.

These three technologies are very powerful and provide a range of possible implementations for network database applications. There is a lot to learn about, but the potential is also quite large. Hopefully this has given you an idea of the possibilities and how the technologies can be used together.

Footnote:
The Developer Roadmap is not an internet resource, however you can get a hold of the CD by calling Microsoft Sales. It has all sorts of sales information as well as info on how all the MS technologies fit together. It is also available, within Autralia, on the Visual Basic Australia '95 conference CD-ROM at a cost of $25.00 plus postage - contact sales@gui.com.au. There are also some interesting bits of information available by going to: http://www.microsoft.com/devonly/, then asking for a search on OLE Development. This information goes into some considerable depth.

You will find that NT machines cope with this overhead really well as they already incorporate OLE2 into the operating system - all the support DLLs are already in memory once NT has booted.

However, Microsoft have committed themselves to OLE and I believe that the support architecture will improve and be better integrated into all Windows platforms in the future. This means that if you move to OLE today, you will probably not have to change to something entirely different in the future.

Remote OLE servers can only be run on 32 bit machines (NT or '95), however they can be produced with both 32 bit and 16 bit VB4.

Hope this helps, cheers.