harleyken said:
I split my database on a personal laptop running 2007. now I need to put
the
be on a network drive (with runtime) that I cannot hook the laptop to..
I tried to save as 2003 format, so I could split it on a networked
computer,
but many forms etc didn't work.
I'm not sure if you understood or misunderstand the process of splitting the
database. The conceptual idea of splitting a database means that you have to
put on a developer's hat, and start thinking like a developer, not an end
user. What this means is that when you split the database, the resulting two
parts are first and foremost your application and software part, and then
you have your data file part. This is not a hard concept to grasp, just like
you have the word application, and that application will in turn open up the
word documents (the data part).
So keep in mind when you split a database you are the developer, and you are
now creating that program part, and the program part will attach itself to
the data part, or in, terminology open the data part. If you've not done so
spend a few minutes reading the following article of mind on why you split
the database here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
The conceptual understanding of why you doing this is more valuable than
just the step by step on how you click on a few options on a menu. I can't
stress how critically important it is to grasp why you're splitting and the
idea of having an application part, and a data part is a critical concept
here.
It is 100% useless to simply have a step by step manual that says this is
how you split by clicking on this and this and this. What you need to
understand is what you're doing and why you're doing it.
There is a significant advantage of splitting a database for an environment
in which you plan to have different version(s) of MS access use the data at
the same time.
Since your data file does not have any forms or code or anything, but ONLY
data, then I doubt that you're going to have any problems converting this
data into 2003 format. The data file is goning to be converted to the lowest
common denominator version of MS access you plan to deploy and have in your
computing environment. In other words if one user has a version of access
2000, then your data file will have to be converted to the lowest common
denominator version, in this example were talking about access 2000. (I
can't read your mind, and don't know your particular situation, but if the
lowest common denominator is access 2002, then that's the format you'll
choose for the data file).
As for the front end (program part), that's a little bit significantly of a
more difficult problem to deal with. What you'll be doing is distributing to
the access 2000 users an access 2000 version of the FE (front end). For the
access 2002 users, you'll have to distribute a 2002 FE, and for 2003 and
2007 etc. the same thing goes.
When in most environments we are going to have to deal with more then one
version of your application part (FE). Usually it tends to be restricted to
two different versions of office/access. What normally occurs is all the
older computers that are running one older version of access/office. As
these older computers are replaced, then of course the new computer has the
newer version of office installed. I can't stress how much of an advantage
it is to standardize on one particular version of office. So, as companies
transition from old to new computers they do often wind up running two
different versions of office at the same time in that transition period.
Therefore it is conceivable that you'll be dealing with two different
versions of your front and in access.
I should also stress out that if you're developing and running access in a
mixed environment, you should be developing and running and testing your
application part on the lowest common version of access. What this means if
your environment is going to have a mixed environment of access 2000 and
access 2007, you'll typically choose to develop under the lower version of
access. What this typically means is you'll be developing your application
under access 2000, and for those 2007 users you'll up convert the FE to a
higher version. The reason for this is of course the during an actual
development process if you develop in access 2007, and then try and down
convert to access 2000, you'll often find many many problems because the new
version has so many more new features. The older version of access likely
will not have those features, and thus you'll have many problems during the
down conversion process. As a general rule in the software industry for good
15 to last 20 years is that applications can always be up converted to the
next version quite easily, but going reversed is very problematic because
often you begin to use a few of the new features that the old version does
not have.
Another potential solution however is to install the access 2007 runtime on
all of the older computers, and thus work only with ONE version of access
for everybody. The problem here is that often the very older computers don't
quite have the processor and memory requirements to run the next great
version of software such as access 2007. Keep in mind that again the last
twenty years every new version of software tends to need about twice as much
memory, twice as much processing, and twice as much or more hard disk space.
only you can decide the state of your machines, and furthermore older
operating systems can run the newer versions of office 2007 anyway (you need
at least windows xp, or windows 2000).
I read the post from "Lateral" and the response(s).
"The code to re-link tables can be found here:
http://www.mvps.org/access/tables/tbl0009.htm
And, the code to popup the file browse dialog can be found here:
http://www.mvps.org/access/api/api0001.htm
So, between the two above routines, in a short time you can cobble
together
some code that can re-link for you."
This post is about splitting, and there is a absolute grand canyon, mount
Everest of a divergence of this topic and discussion at hand and now all of
a sudden this turns into a question about where to place and paste code? As
a suggestion in the future it's probably not a very good idea to place a
question buried deep inside of a post with a completely unrelated topic of
spilitting.
I'm mention this issue, as it has little to do with software, but just a
general tip on the whole process of learning, and how normal newsgroup
discussions flow. However take heart as you actually did make a new post on
the code cut/paste issue (good idea), and you'll see that I gave an answer
to your question on that subject issue also....
