Here's a follow up question - If we KNOW that noone is going to be logged
onto the database for 30 minutes every day, why would we use the split
method
instead of the develop and import method?
Well, it is kind of funny, since the first question was how dumb it is to
have to kick out users. Now, we are starting to split hairs about knowing
that people are going to be logged out...maybe they are...maybe they are
not!!
Fact is, when people go for coffee, answer the phone...and *then* run out
for lunch..they often will NOT log out.
So, really, some debate about users logged in or not is rather silly when
you can run a split database. Also, running a split database allows you to
test the production version in a much easier fashion.
Not sure how effortless this
utility is, but as long as you tack on a date modified to the object name
it
should be easy to Import all new objects at once, right?
Gee, why even bother will all the work to track object names, object
dates..and go through some big import, or update process? Forget all of that
junk and simply distribute a brand new mde for use (these folks if at all
experienced do distribute a mde to each desktop..right???)
So, gee, object dates, importing...forgetting to import something..testing
after you import because you might forget one line of code that got changed
in some module...huh? I am trying hard to come up with a argument here for
some complex object tracking concept? Why even bother with such a complex
idea?
To update a with a split database is a simple file copy...not some complex
import thing that has to check and figure out object dates!
All I am saying is that running a split system is really nice. And, if you
think about all other software on your pc now...how is it setup?
If you think about this...it makes NO sense to have the code and data in the
same object. Can you imagine if when updating ms-word, you have to update
all the documents too? Fact is, when a new version of word comes out..you
install a new application on each computer (msword.exe). In the case of
ms-access applications, you issue a new application (usually a mde) and that
also goes on each new pc. However, that application is separate from the
word documents (in the case of word), and separate from the data in the
access application in the case your products that you develop.
So, I think we all realize that it makes sense to install Word, or Excel, or
whatever application is being made on each computer.Sure, we might share
some word documents on a server. And, we might even share some Excel
documents on a server. And, if you write you way cool job costing system in
ms-access, then just like every other program you can share the data on the
server. However, the actual application YOU make is installed on EACH pc
(just like every other application is installed). Remember, ms-access is a
development tool like VB, c++ or whatever. This is a product that creates
software. And, software you purchase (or crease for that matter) is
installed on each pc.
Of course, the data part can be shared on the server (just like we do with
word, or excel..but NO ONE is suggesting to install word, or Excel on the
server!!!). So, all these applications have the program and interface part.
This part of the application gets instated on each pc. And, most of the
programs then also have a data part they work with. Often, each program is
given their own extension. In fact, sometimes even people who use ms-access
database formats do this (for example, did you know the VERY popular Simply
Accounting software is based on the ms-access database format?). So, lots of
commercial products actually use the ms-access format..but they change the
file extensions (I don't think you need to do that...as it is not a big
deal).
So, assuming that these people have used word, or Excel etc, then I have to
assume they realize that these applications are installed on each pc. I also
have to assume that most developers realize it makes sense to separate the
application part from the data part. I think that just basic observations of
how just about every software product works would make this issue very clear
and obvious. Software created with ms-access is an exception to this rule in
that it allows you to have both data and the application part in the same
file. However, while we *can* do this, any developer will rapidly realize
this is a bad setup. Thankfully, ms-access does let one split the
application into a data part, and a application part, just like 99% of all
other software that developers create.
In a sense, all you have to do is look at how most software is setup...and
you will realize that splitting makes perfect sense. You really don't need
me to tell these people what is common sense..and how 99% of software being
run works this way..
