Linking tables vs. Opening tables directly
Scott,
With linked tables, you don't loose anything you can still access the
database as if it was not linked if you wish (the Seek method is used on a
recordset which can be from linked and none-linked tables.) When you deploy
on a network, you simply link your data tables to a network drive. And you
can do this in VB (there are a lot examples on msdn also Northwind has
routine that show how it is done).
And yes it makes things harder if you don't link tables, you cannot bound
forms and controls and then you have to fill and update the data back and
forth all the time.
As for the EXE thing, Access (or VB) is a pseudo compiled language that
needs an interpreter program and a bunch of DLL's to run. So you cannot
produce an EXE like in Delphi or C++.
---
Mike S.
Optimal Systems Corp. www.oscorp.com
---
Quote:
> My question relates to using Access 97.
> I am a fairly new access programmer but I have done a lot of programming
> work in the past in the other environments such as FoxPro, Delphi, C,
etc..
> I'm struggling with a design issue. I want my application to be a split
> database (data kept in a separate .mdb file from the forms, reports,
etc.).
> Obviously this is to make it easier to update the application, not to
> mention the fact that the client stipulated that it be done that way.
> My learning curve on this seems to be rather steep because I am not used
to
> having the data bound with the application like Access inherently does.
> Between two different projects, one will have the data stored locally on
the
> computer's hard drive and the other will have the data located on a file
> server volume, although not running under a SQL server engine. My primary
> concern at this point is the latter of the two which will have the data on
> the file server.
> From what I understand my two options are linking to the remote tables or
> opening the remote tables directly. There seems to be pros and cons with
> both methods but I wonder what most people use; or do they use a
combination
> of both? If I choose not to link the tables will that make creating and
> designing forms much harder? I know I will not be able to use drop-down
> lists to select properties such as Control Source in data bound controls,
> but it is there any other drawbacks such as that?
> If I do link the tables I lose the Seek method (because it's then a
> dynaset), and Seek seems awfully useful for doing efficient data retrieval
> in a non-SQL environment. True? Or, is it sufficient to adopt SQL
> retrieval methods to use under the MS Jet Engine. For example, using a
> Select statement to retrieve information that I would otherwise Seek.
> Is it common to open and/or link all tables programmatically instead of
> through the interface? I assume it would almost have to be after you
> distribute the application since the data at the target site is likely
> stored in a different location than it is at the development site. Of
> course if I open the tables directly it would have to be done
> programmatically anyway. True?
> Not sure if I explained this very well but if you would like me to clarify
> something I would be happy to do so. My goal is not have to redo a major
> chunk of the program in a month because of poor design now. Of course
> that's always the goal isn't it?
> I should also mention that at least one of these projects is going to be
> compiled into an EXE. They will also be converted to Access 2000 but I
> suspect that statement opens a whole new can of worms. If you know of any
> resources on the net, or any good books that delve into this type of
thing,
> I would love to hear about those also.
> Thanks in advance,
> Scott
> --
> Scott Millhisler
> SJM Computer Consulting - Perry, MI USA
> http://www.sjm.net
