db*******@hotmail.com wrote:
wow what do you mean you want to give it to your users?
you should start with using ACCESS DATA PROJECTS instead of MDB since
they have a lot more ability to work for BCP for example
It depends on what the developer is doing.
Large database apps that serve as repositories of information in, for
example, a facilities management environment (space management
information, work orders, trades, shops, clients, sub-clients, materials
handling, purchasing, etc) are used by a wide variety of users and will
very often want to be able to bring in data from other sources so that
disparate sources of data scattered all over the place can be brought
together in a relational (no theoretical arguments about Jet as an
RDBMS, please) database structure. There will always be little isolated
islands of information out there, or stand-alone projects that
eventually will want to be married with your own app. An example of the
latter could a list of 600kV + transformer substations which may be part
of an equipment table in an application, but new regulatory requirements
(perhaps based on a fatality in your own organization or elesewhere)
that require physical inspection and verification are often best handled
with a separate stand alone data gathering tool - once such an exercise
is complete and an analysis of whether or not the existing structure you
have can accomadate the new regulatory regime has been performed, then
you can start bringing in the new data. How that new data was acquired
should be based on what the project personnel involved with it are
comfortable with, but you do need to dictate to them certain basic
precepts. Nevertheless, you're going to be faced with bringing in data
to the main database structure and the ability to deal with many
different forms is desirable.
Just another perspective. My huge apps like this are on Oracle anyway,
and not Jet.
--
Tim
http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me