My ritual question for each new version of Access since 2000

It also seems impossible to open the library in another Access instance
and modify it.

Have you tried using source code control?
access 2003 has a source code control add in, and when you use it, you can
check in,/ check out code, queries, forms etc. In fact, what is really nice
is that you can actually check out queries....and check them back in!! (I
can't think of any ide that allows this).

I not tried the above, but for most serious development, people do use
source code control. Perhaps it would be a solution in your case....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

May 31 '06 #3

>Perhaps it would be a solution in your case....

In thinking about this, likey it would NOT solve your problem. My next best
suggestion would be to ALWAYS set a reference to a mde, and that way, you
can open/browse/modify the mdb that the mde libary is based on. That should
work. If you *do* make changes to the libary code, the you would have to
wait untill you exit the appcaton that is "holding" the mde.

I am rather surprixed that you can catuly set a refernece to a mdb file
anway (a mde at elast forces the code to be compiled).

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

May 31 '06 #4

opps...bumped the sned key...

Perhaps it would be a solution in your case....

In thinking about this, likely it would NOT solve your problem.

My next best
suggestion would be to ALWAYS set a reference to a mde, and that way, you
can open/browse/modify the mdb that the mde library is based on. That
should
work. If you *do* make changes to the library code, the you would have to
wait until you exit the applications that is "holding" the mde.

I am rather surprised that you can actually set a reference to a mdb file
anyway (a mde at least forces the code to be compiled).

Would not the above approach sole this problem? You can't for most part edit
the executable part in any other development platform anyway. So, I am not
sure why you need to do somthing that no other develpuemt patform allows?

This is not a "new" problem.

We *could* do this in a97, but it was not recommended anyway. It seems if
you use a mde for your library code, this should then work...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

May 31 '06 #5

And all they had to do was provide a switch to load
libraries in exclusive mode.

They even could have used the same switch used by
Application: if CurrentDB is loaded exclusive, load
libraries exclusive.

It's bad enough that they couldn't build a multi-user
database system to store the VBA project in. (Apparently
they had problems with referential integrity)

But you sometimes think that being assigned to
the MS Access project must have been some kind of
punishment for people whose hearts really aren't
in it.

(david)
"Mathieu Trentesaux" <ma***************@free.fr> wrote in message
news:44**********************@news.free.fr...

Hello

I downloaded Office 2007 for this reason :

It seems, once again, that it is impossible to save any modification done
in a VBA library, from the main project in Access.

The save button remains desperatly grayed.

It also seems impossible to open the library in another Access instance
and modify it.

This makes impossible to maintain a pure VBA Access database when this
library can only be tested in the context of the main project.

In fact this makes impossible to make some meta-programmation whith
access. This is -and has always be- my only way to work.

So my question is, ritual since six or seven years : is there a
possibility to explain Access that only one person in a single instance of
Access is about to modify this file ? or something very simple like that ?

Mathieu, lonesome, desperate.

May 31 '06 #6

> In thinking about this, likey it would NOT solve your problem. My next

suggestion would be to ALWAYS set a reference to a mde, and that way,
can open/browse/modify the mdb that the mde libary is based on. That

If only it were true.

If you have ever had the reference library mde loaded, you need to
close Access before you can work on the library source code.

Otherwise, Access suspects you are 'sharing' the source file.

Access doesn't unload libraries, and it won't differentiate between
the mde file (loaded once with no editing done or possible) and the
mdb file (never loaded or edited by anyone).

Since the developers of Access 2000 where unable to get their heads
around the idea of multiple users sharing text in a database, they
handed the problem off to the SourceSafe people.

The SourceSafe people were able to provide a file based multi-user
database to store text in. Perhaps some of the Access 2.0 developers
had moved to that project.

(david)

"Albert D.Kallal" <Pl*******************@msn.com> wrote in message
news:5z9fg.215681$WI1.178977@pd7tw2no...

Perhaps it would be a solution in your case....

In thinking about this, likey it would NOT solve your problem. My next
best suggestion would be to ALWAYS set a reference to a mde, and that way,
you can open/browse/modify the mdb that the mde libary is based on. That
should work. If you *do* make changes to the libary code, the you would
have to wait untill you exit the appcaton that is "holding" the mde.

I am rather surprixed that you can catuly set a refernece to a mdb file
anway (a mde at elast forces the code to be compiled).

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

May 31 '06 #7

w_a_n_n_a_l_l_ -

Sounds like the only option that will work is to set a reference to the MDE
in your live project, and then wait until last user is out to replace that
MDE.

I haven't seen the problem you describe of not being able to modify the MDB
just because someone is in the MDE. I can imagine the possibility that if
you put the MDB and the MDE of the library in the same directory, presumably
having the same name other than MDB and MDE, since you can only have one LDB
you could have a problem. But the real problem there is putting both MDB
and MDE in the same production directory. One or the other, but not both,
ever.

And in development, since you have to be out of the main project to release
the MDE anyway, there shouldn't be a problem with modifying the MDB and then
creating the MDE.

May 31 '06 #8

w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t wrote in
news:FA*****************@newssvr14.news.prodigy.co m:

Sounds like the only option that will work is to set a reference
to the MDE in your live project, and then wait until last user is
out to replace that MDE.

I don't know if that is what is meant or not. That would only be a
problem if you're sharing the library, and, well, why in the world
would anyone in his right mind do that?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

May 31 '06 #9

I'm not sure what you're after with the "sharing the library" observation.

If the user has an application MDB Or MDE in the same directory as a
reference library file (MDA, whatever), then that library is shared the
moment two people use the app. Am I misunderstanding your question?

May 31 '06 #10

"Rick Wannall" <wa*****@notadomain.de> wrote in
news:LW********************@newssvr29.news.prodigy .net:

I'm not sure what you're after with the "sharing the library"
observation.

If the user has an application MDB Or MDE in the same directory as
a reference library file (MDA, whatever), then that library is
shared the moment two people use the app. Am I misunderstanding
your question?

When in the world would anyone have two people opening the same
front end?

Except an incompetent developer?

Yes, back ends are shared. Sure.

Front ends never are, except by those who haven't a clue what they
are doing.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

May 31 '06 #11

I can only speak from experience, and we regularly have 20 or more users in
one of our front ends on a network file server. I can't say that it's caused
us any particular headaches.

Of course, running an MDB over a network is itself a bit of a load. That's
why I would agree that having users share a front end is not preferred,
because it means that you're going over some network, not particularly
because of sharing in and of itself.

We've probably just been lucky.

Have you experienced difficulties related to having multiple users in a
single front end?

RW

On 5/31/2006 6:01:52 PM, "David W. Fenton" wrote:

"Rick Wannall" <wa*****@notadomain.de> wrote in
news:LW********************@newssvr29.news.prodig y.net:
I'm not sure what you're after with the "sharing the library"
observation.

If the user has an application MDB Or MDE in the same directory as
a reference library file (MDA, whatever), then that library is
shared the moment two people use the app. Am I misunderstanding
your question?

When in the world would anyone have two people opening the same
front end?

Except an incompetent developer?

Yes, back ends are shared. Sure.

Front ends never are, except by those who haven't a clue what they
are doing.

--
Science is organized common sense where many a beautiful theory is killed by an ugly fact (Thomas Huxley).

Jun 1 '06 #12

I personally close my one copy of access every time I leave
a source file.

I personally can't work on bs9.mdb in my one copy of Access
if I have been working on rp9.mdb, because rp9.mdb loads
bs9.mde.

One user. One application. Two different files. Nothing
shared at all. Not shared between users. Not shared between
instances. Not shared at all.

One stupid poorly planned VBA implementation that can't tell
the difference between two files with similar names.

One stupid poorly planned VBA implementation that can't tell
that there have been no source changes to an MDE loaded in
shared mode, even though (a) it won't let you make changes
to an MDE, and (b) it won't let you make changes to a file
loaded in shared mode.

One stupid poorly planned VBA implementation that won't
unload an MDE so that you can edit an MDB.

One stupid poorly planned VBA implementation that makes
me close and re-start Access scores of times every day.

(david)

<w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t> wrote in message
news:FA*****************@newssvr14.news.prodigy.co m...

Sounds like the only option that will work is to set a reference to the
MDE
in your live project, and then wait until last user is out to replace that
MDE.

I haven't seen the problem you describe of not being able to modify the
MDB
just because someone is in the MDE. I can imagine the possibility that if
you put the MDB and the MDE of the library in the same directory,
presumably
having the same name other than MDB and MDE, since you can only have one
LDB
you could have a problem. But the real problem there is putting both MDB
and MDE in the same production directory. One or the other, but not both,
ever.

And in development, since you have to be out of the main project to
release
the MDE anyway, there shouldn't be a problem with modifying the MDB and
then
creating the MDE.

Jun 1 '06 #13

In summary:

So, we have a mdb we are developing. We also have a nice "library" of
routines that we built up over the years, and we wish to share this code
among "many" mdb files. So, you place all those routines in a mdb file, and
then create a mde. Now, while in the code editor, you go tools->references
and click on browse..and add this mde to your references. Now, all your
applications you write can use this "library" of code. And, you only have
to maintain ONE COPY of this code. A nice feature.

That means, you set a reference to ANOTHER mde file from the existing one.
A
reasonable setup,. and I have used many systems that support the concept
of a shared library of code. Even going back many years ago using Pascal on
the Apple I used this library concept to develop a payroll system.
I have to admit, that have one common place for all of my code to be
used by all of my applications is a great concept.

However, for ease of distribution, I don't use references to other mde's
in my ms-access applications since if you move the application, then
it will break

You seem to be pointing out that when you open up a mdb that has a REFERENCE
to
another mde file, that mdb file is ALSO LOCKED, and thus can't be modified.

This means that you can't view, check up things to refresh one's memory,
or simply edit the library code while a application has a reference to that
mde.

I will certainly agree that if the referenced library is a mdb, then of
course
you can't open it until you exit the current mdb that has a reference to
that
mdb.

However, I was NOT aware this was the case if you use a mde, and you can't
open the mdb. I am going to test this right now.....

<testing>

You are Correct!.

However, there is a simply solution:

The simple solution is to use a mde, and NOT place the original mdb that
created the library code in the SAME directory. If this done, then the
original mdb used to create the libary can be opened.

So, you can well edit, and view, and even modify your library code. You will
have to exit the original mdb when you need to re-compile the library mdb
(however, that can't be much of a problem -- if you are constantly modifying
your library code, then it SHOULD NOT be library code!!!

So, to the original poster, simply use a mde for your library reference, and
NOT PLACE the mdb used to create this library in the same directory. If you
do this, then you CAN FREELY OPEN AND EDIT/MODIFY the mdb used to create the
mde....

I really don't think the above is a problem worrying about at all.... The
above is a sensiable work around...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 1 '06 #14

Well, if you are dumb enough to put two files in the same directory with the
same name, ms-access creates a locking file based on the filename.

So, even if you are not using library code, you always had to avoid this
problem.

The solution is to move out the mdb from the directory that created the mde.
Another solution is to name the mdb and the mde file differently.

As I pointed out in my other post, it is not really a big deal. You can't
have multiple users editing the code. However, you can edit the mdb used to
create the mde (if you move it to a different dir, or give it a different
name). Remember, even your workgroup file name has to be different. I once
made the mistake of naming my workgroup file the same "prefix" name as the
mdb. Don't do that!!

The reason is that ms-access also creates a .ldb file for EACH application
it opens (this includes workgroup files, and library files).

So if you have

mydb.mdb
mydb.mde
mydb.mdw

In the above 3 files, they all have the same prefix. Only ONE locking file
can be created called

mydb.ldb

so, tell me Sherlock, to which of the above 3 applications does the ldb file
apply to? You got a real mess here.

So, if the original poster simply adopts a naming convention, or simply
places the mdb file in a different directory then the mde file, then that
person CAN FREELY OPEN and edit the library mdb file.

The stated problem GOES AWAY. It is a trivial matter to avoid the original
posters problem. If you are telling me that the fact of ms-access creating a
ldb file based on the file prefix name is a problem, I have no beef with
that. However, this is not a new problem.

There is few, if any IDE's that allow multiple users into the same code base
at the same time. It is just not done, and the fact of this being changed
from a2000 onward is a moot point if one *slightly* changes their
development practices.

If a person can't adopt the simple and slight changes in their approach to
developing software, then I have to question that persons ability to develop
software.

The suggestions I made in other responses to this post are of a VERY minor
change in coding and approach. This changes will not result in ANY drop, or
loss of productivity in any measurable way that I can think of.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 1 '06 #15

No, see my other posts. We are not talking about two users here!!!

It is the use of library references to a mde that is casing this problem.
The simply solution is to move the mdb OUT OF the directory where the mde
file is....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 1 '06 #16

w_a_n_n_a_l_l_ -

On 1-Jun-2006, "Albert D.Kallal" <Pl*******************@msn.com> wrote:

if you are constantly modifying
your library code, then it SHOULD NOT be library code!!!

OP: Read and heed. If you are still constantly changing the library code,
put it back in the application until it's essentially solid. THEN it's
ready for library status.

ADK is right on the money.

Jun 1 '06 #17

"Rick Wannall" <wa*****@notadomain.net> wrote in
news:AX*******************@newssvr11.news.prodigy. com:

I can only speak from experience, and we regularly have 20 or more
users in one of our front ends on a network file server. I can't
say that it's caused us any particular headaches.
It's asking for trouble. There is no logical reason to share
anything other than what *needs* to be shared. You wouldn't share an
installation of MS Word on a server, so why would you share your
Access application's front end? It should be installed and run from
the local workstation.
Of course, running an MDB over a network is itself a bit of a
load. That's why I would agree that having users share a front end
is not preferred, because it means that you're going over some
network, not particularly because of sharing in and of itself.
Sharing the front end leads to corruption, and very quickly. That
tendency was not nearly as great in A97, but with A2K, it became
quite severe. I've never seen anyone manage to run an A2K
application in shared mode for any length of time without
corruption.
We've probably just been lucky.
Phenomenally so.
Have you experienced difficulties related to having multiple users
in a single front end?

Or course I have, because I've actually seen it tried a number of
times. Two of my largest clients over the last 5 years came to me
when they started having corruption because of trying to share the
front end. I immediately moved them to non-shared front ends and all
the corruption went away.

D'oh.

This is Access 101.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Jun 1 '06 #18

Thanks for the info.

Jun 1 '06 #19

Our whole application is library code. It is called
from a shell.

I write code for a living. I'm not the application /user/.

I agree that application /users/ should not be using the
code I am developing.

I need to work on and test library code. It is what I do.

I need to close Access after each test, so that I can
re-open Access to work on the code.

Obviously, for people who don't test as they work, this
will not be a problem.

(david)

<w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t> wrote in message
news:u1*****************@newssvr14.news.prodigy.co m...

On 1-Jun-2006, "Albert D.Kallal" <Pl*******************@msn.com> wrote:
if you are constantly modifying
your library code, then it SHOULD NOT be library code!!!

OP: Read and heed. If you are still constantly changing the library
code,
put it back in the application until it's essentially solid. THEN it's
ready for library status.

ADK is right on the money.

Jun 2 '06 #20

> Well, if you are dumb enough to put two files in the same directory with

the same name, ms-access creates a locking file based on the filename.
Yes, this is the way Access works by default. MDE in the same folder as MDB,
and with the same project name.

But even if you call this dumb, the problem with locking is bigger than
that. It's not to difficult to lock up a file even if you are the only
user in a new instance of Access.

(david)

"Albert D.Kallal" <Pl*******************@msn.com> wrote in message
news:Rsxfg.219740$WI1.4495@pd7tw2no... Well, if you are dumb enough to put two files in the same directory with
the same name, ms-access creates a locking file based on the filename.

So, even if you are not using library code, you always had to avoid this
problem.

The solution is to move out the mdb from the directory that created the
mde. Another solution is to name the mdb and the mde file differently.

As I pointed out in my other post, it is not really a big deal. You can't
have multiple users editing the code. However, you can edit the mdb used
to create the mde (if you move it to a different dir, or give it a
different name). Remember, even your workgroup file name has to be
different. I once made the mistake of naming my workgroup file the same
"prefix" name as the mdb. Don't do that!!

The reason is that ms-access also creates a .ldb file for EACH application
it opens (this includes workgroup files, and library files).

So if you have

mydb.mdb
mydb.mde
mydb.mdw

In the above 3 files, they all have the same prefix. Only ONE locking file
can be created called

mydb.ldb

so, tell me Sherlock, to which of the above 3 applications does the ldb
file apply to? You got a real mess here.

So, if the original poster simply adopts a naming convention, or simply
places the mdb file in a different directory then the mde file, then that
person CAN FREELY OPEN and edit the library mdb file.

The stated problem GOES AWAY. It is a trivial matter to avoid the original
posters problem. If you are telling me that the fact of ms-access creating
a ldb file based on the file prefix name is a problem, I have no beef with
that. However, this is not a new problem.

There is few, if any IDE's that allow multiple users into the same code
base at the same time. It is just not done, and the fact of this being
changed from a2000 onward is a moot point if one *slightly* changes their
development practices.

If a person can't adopt the simple and slight changes in their approach to
developing software, then I have to question that persons ability to
develop software.

The suggestions I made in other responses to this post are of a VERY minor
change in coding and approach. This changes will not result in ANY drop,
or loss of productivity in any measurable way that I can think of.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 2 '06 #21

w_a_n_n_a_l_l_ -

There's something I'm not understanding now.

Are you saying that you do work with the MDB and the MDE made from it (using
the same name before the ".mde") in the same directory, attempting to open
both of them at the same time?

Jun 2 '06 #22

> There is few, if any IDE's that allow multiple users into the same code

base at the same time. It is just not done, and the fact of this being

Source Safe allow multiple users into the same code base at the same time.

Actually, Source Safe even allows multiple users to modify the same text
file at the same time, then merges the changes. (It won't do that for
Access because Access locks you out of the interface).

Visual Basic allows multiple users into the same code base at the same time.

But worse than that, Access, like Source Safe, is supposed to be a
multi-user
database. If the developers can't handle data integrity for the VB project
stored in the Access database, what confidence does that give you?

None at all: and Access 2000/Jet 4.0/Windows 2000 corrupted data.

If they have fixed the problem with not being able to handle data integrity
in a multi-user database, they need to go back and fix the VBA project they
store in the database.

I have some sympathy for the VBA6 integration team working on Access 2000:
they had to store the VBA project in a broken database system.

But my sympathy has expired: They've had 6 years and they should have fixed
it.

(david)

"Albert D.Kallal" <Pl*******************@msn.com> wrote in message
news:Rsxfg.219740$WI1.4495@pd7tw2no... Well, if you are dumb enough to put two files in the same directory with
the same name, ms-access creates a locking file based on the filename.

So, even if you are not using library code, you always had to avoid this
problem.

The solution is to move out the mdb from the directory that created the
mde. Another solution is to name the mdb and the mde file differently.

As I pointed out in my other post, it is not really a big deal. You can't
have multiple users editing the code. However, you can edit the mdb used
to create the mde (if you move it to a different dir, or give it a
different name). Remember, even your workgroup file name has to be
different. I once made the mistake of naming my workgroup file the same
"prefix" name as the mdb. Don't do that!!

The reason is that ms-access also creates a .ldb file for EACH application
it opens (this includes workgroup files, and library files).

So if you have

mydb.mdb
mydb.mde
mydb.mdw

In the above 3 files, they all have the same prefix. Only ONE locking file
can be created called

mydb.ldb

so, tell me Sherlock, to which of the above 3 applications does the ldb
file apply to? You got a real mess here.

So, if the original poster simply adopts a naming convention, or simply
places the mdb file in a different directory then the mde file, then that
person CAN FREELY OPEN and edit the library mdb file.

The stated problem GOES AWAY. It is a trivial matter to avoid the original
posters problem. If you are telling me that the fact of ms-access creating
a ldb file based on the file prefix name is a problem, I have no beef with
that. However, this is not a new problem.

There is few, if any IDE's that allow multiple users into the same code
base at the same time. It is just not done, and the fact of this being
changed from a2000 onward is a moot point if one *slightly* changes their
development practices.

If a person can't adopt the simple and slight changes in their approach to
developing software, then I have to question that persons ability to
develop software.

The suggestions I made in other responses to this post are of a VERY minor
change in coding and approach. This changes will not result in ANY drop,
or loss of productivity in any measurable way that I can think of.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 2 '06 #23

<w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t> wrote in message
news:_E****************@newssvr12.news.prodigy.com ...

There's something I'm not understanding now.

Are you saying that you do work with the MDB and the MDE made from it
(using
the same name before the ".mde") in the same directory, attempting to open
both of them at the same time?

No, of course not. You could only do that in the multi-user versions of
Access.

I'm saying that I attempt to open only the mdb, and that I have to
close and re-open Access to do that.

(david)

Jun 2 '06 #24

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:44***********************@lon-reader.news.telstra.net...

There is few, if any IDE's that allow multiple users into the same code
base at the same time. It is just not done, and the fact of this being

Source Safe allow multiple users into the same code base at the same time.

No, it does not. VSS makes a *copy* and gives that to each user. That is
*big* difference!! They are NOT sharing one copy. Each user in fact has a
"local" build of the application based on the source safe. They are NOT
sharing the same code at the same time. As I said before, I don't know of
*any* environments that allowed what was possible in a97.
Actually, Source Safe even allows multiple users to modify the same text
file at the same time, then merges the changes. (It won't do that for
Access because Access locks you out of the interface).
If you have the code checked out, then others can't modify it. This is
rather normal when using VSS with ms-access, or most any product when used
with VSS.

Visual Basic allows multiple users into the same code base at the same
time.
No, it does not. It *does* allow users to edit a *different* form, but that
is because VB projects are simply a collection of *separate* files on the
hard disk, and ms-access is not. Two users cannot edit the same form, or
source code for a given form in VB at the same time. They most certainly can
open *different* forms+code.

However, if you use VSS with ms-access, then multiple users can each work on
forms, reports or anything else that they checked out of the project. This
is no different if you us VSS with VB6, or use it with ms-access. So, you
*can* well have multiple developers working on a ms-access application if
you use VSS (and, that is exactly what VSS is for!!).
But worse than that, Access, like Source Safe, is supposed to be a
multi-user
database. If the developers can't handle data integrity for the VB project
stored in the Access database, what confidence does that give you?

Your abilities to have multiple users working on the same project in
ms-access, or vb6 are the same if you use VSS.

The original problem stated in this thread was about using a library file,
and how it is locked. The simple solution is to move out the library mdb
from the directory of where you place the library mde.

As for multiple developers working on the same ms-access application, this
problem is solved by using VSS. When done, you have the same flexibility as
those other platforms.

I just don't see the downside here....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 2 '06 #25

Yes, this is what a database does.

You get a copy of a record, make changes, then send it back.

You can have exclusive locks, or shared write locks, or
lots of other kind of locks. And yes, Source Safe, in
normal use, allows optimistic locking, multiple check-outs,
and merge updates.

Access used to get a copy of a form out of the database,
allow you to make changes, then save the form back to
the database. If some other user had in the same time
made changes, you were asked if you wanted to keep or
discard your changes.

Access still does this, but it uses a Source Safe database
instead of using an Access database. (And the interface
only allows pessimistic locking)

MS was apparently unable to get it to work in A2000 using
an Access database to store the forms instead of using a
Source Safe database to store the forms.

It would be nice if MS connected up a Jet database to the
VBA project, and allowed us to check forms in and out of
the Jet database, as they did in Access 2.0 and Access 97.

VB has (had) a similar system. I can open two VB projects using
shared text: the text is copied from disk to memory. VB is not
very sophisticated at all: I can save one copy of the text, then
save the other copy right over it, without any warning at all.
You can do better than that, and some versions of VB came with
a Source Safe licence.

Access, like VB, had a two level system: forms stored in an
Access database for the current copy, forms stored in a source
safe database for the historical copies. The Access database
system was a relational database system, the native VB system
was 'just a file system' -- the kind of thing people always
used to wrongly say about Access "its just a file based system",

The Jet database is not 'just a file'. It is a least as good
as the Source Safe database (which is based on the same OS
file system database primitives).
Next, every general programming text of the last 25 years has
talked about the importance of good tools and good processes
for good code.

Yes, you can use slower and more complicated processes: yes
there is a downside to using slower and more complicated
processes, yes the Access defaults are incompatible with
the processes you recommend, yes there is a downside to processes
which are not compatible with the system defaults.

And yes, Source Safe is not a good tool: That process is not a
good process. Harsh words, but widely accepted.

Yes, we tried using Source Safe for several years. Obviously,
I know more about Source Safe than you do, because you don't
even know about multiple check-outs and merge updates.

Yes, for our large application, it's even worse than closing and
re-opening the Access application, and no, it doesn't even solve
that problem.

The original comment was about the inability of Access to allow
a single user to save the single copy of a single file that he
had opened (as a 'reference') and could read and edit.

That's a problem because Access incorrectly assumes multiple
users: (references are opened in shared mode)

That's a problem (apparently and obviously) because they had
problems maintaining referential integrity between the code
text and the compiled code.

That's an indication of wider problems: they don't trust or
can't maintain their own database system, and they can't be
bothered fixing the usability issues.

As such, it's a valid ritual question for each new version of Access.

And yes, even if they fixed the usability issues in Access there
would still be a place for Source Safe (or a better product).
Source Safe is a version control database: Relational database
systems are not a natural choice for version control databases,
and the 2GB file limit means that you can run into byte limits
when storing multiple versions of a database in a database.

(david)

"Albert D.Kallal" <Pl*******************@msn.com> wrote in message
news:cGTfg.222201$P01.112446@pd7tw3no...

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:44***********************@lon-reader.news.telstra.net...
There is few, if any IDE's that allow multiple users into the same code
base at the same time. It is just not done, and the fact of this being

Source Safe allow multiple users into the same code base at the same
time.

No, it does not. VSS makes a *copy* and gives that to each user. That is
*big* difference!! They are NOT sharing one copy. Each user in fact has a
"local" build of the application based on the source safe. They are NOT
sharing the same code at the same time. As I said before, I don't know of
*any* environments that allowed what was possible in a97.
Actually, Source Safe even allows multiple users to modify the same text
file at the same time, then merges the changes. (It won't do that for
Access because Access locks you out of the interface).

If you have the code checked out, then others can't modify it. This is
rather normal when using VSS with ms-access, or most any product when used
with VSS.

Visual Basic allows multiple users into the same code base at the same
time.

No, it does not. It *does* allow users to edit a *different* form, but
that is because VB projects are simply a collection of *separate* files
on the hard disk, and ms-access is not. Two users cannot edit the same
form, or source code for a given form in VB at the same time. They most
certainly can open *different* forms+code.

However, if you use VSS with ms-access, then multiple users can each work
on forms, reports or anything else that they checked out of the project.
This is no different if you us VSS with VB6, or use it with ms-access. So,
you *can* well have multiple developers working on a ms-access application
if you use VSS (and, that is exactly what VSS is for!!).
But worse than that, Access, like Source Safe, is supposed to be a
multi-user
database. If the developers can't handle data integrity for the VB
project
stored in the Access database, what confidence does that give you?

Your abilities to have multiple users working on the same project in
ms-access, or vb6 are the same if you use VSS.

The original problem stated in this thread was about using a library file,
and how it is locked. The simple solution is to move out the library mdb
from the directory of where you place the library mde.

As for multiple developers working on the same ms-access application, this
problem is solved by using VSS. When done, you have the same flexibility
as those other platforms.

I just don't see the downside here....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 2 '06 #26

"Albert D.Kallal" <Pl*******************@msn.com> wrote in
news:cGTfg.222201$P01.112446@pd7tw3no:

The original problem stated in this thread was about using a
library file, and how it is locked. The simple solution is to move
out the library mdb from the directory of where you place the
library mde.

That's not really a solution, as it's a matter of recognizing that
you can't ever edit the MDE, which was the original complaint, no?

I don't see the issue, myself, since I can't see why this would be
an issue during regular development. As someone said, if you're
still developing, you shouldn't have split out your code into a
separate library yet -- that's a premature optimization.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Jun 2 '06 #27

OK. I'm more with you now.

Next question: To what do you refer when you speak of "multi-user versions
of Access"?

I only know of one version of Access.

Jun 2 '06 #28

> as it's a matter of recognizing that
you can't ever edit the MDE, which was the original complaint, no?

Good point.....

In fact, it *seems* that a MDB was being used for the library code, and NOT
a mde. As mentioned, one *can* use a mdb, but I would strongly suggest that
a mde is used.

So, it is/was not 100% clear if in fact a mde was being used, but EITHER
way...simply move a copy out of the current dir, and it can be edited. The
user can decide to create a mde, or simply "copy" the new mdb to the
production dir. Either way, the locking problem is avoided...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 2 '06 #29

>That's a problem because Access incorrectly assumes multiple
users: (references are opened in shared mode)

Not at all. it is not a problem. The issue here is that we are failing to
distinguish between source, and object files. You can't have a dll loaded,
and in use, and then try to re-compile that library file. You have to let
the .dll be un-loaded first. Again, I can't stress how this is a normal
facet of any development platform.

If the poster uses a mde for the library file (that is our OBJECT code!!!),
and edits the source code (the mdb file), then is NOT a problem here.
As for having two users merge code with VSS + ms-access. I don't think that
was ever allowed, and for the most part I don't see why it would be needed
anyway.

There is no question that from a97 to a2000, the moving of the object code
out of the database system was a step backwards. For the most part, a SIGHT
change in development processes, or the adoption of VSS more then solves
these issues...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 2 '06 #30

> Next question: To what do you refer when you speak of "multi-user

versions
of Access"?

He means access97, and previous versions.

Those pervious versions allows MORE then on person to be in the SAME
database, and BOTH COULD make modifications to different forms....

You can't do the above since a2000...and later.....(only ONE person can
enter into forms design mode, and you need exclusive access to do this --
hence, they are in a lame sense non-multi user when developing).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

Jun 2 '06 #31

Mathieu Trentesaux

david epsom dot com dot au wrote :

Our whole application is library code.
[...]
I need to work on and test library code.
[...]
I need to close Access after each test, so that I can
re-open Access to work on the code.

Before Access 1, I was working with Quick Basic (7,4,2) under Dos. Again
before QB I was working with Bascom86 plus an editor (Edix, Edlin) : the
problem we talk about brings me back to these ancients times... Test,
edit, compile...

Well david, I see that, at least, I'm not the only one having this
problem. What would you say about this kind of solution :

We make a button somewhere in Access which aim is to write each module
of the Library.Mdb in a new Access database named for instance
Library.Tmp. This button is done to replace the grayed save button.

When leaving Access, we launch a batch :
IF EXISTS Library.Tmp DEL Library.Mdb
IF EXISTS Library.Tmp REN Library.Tmp Library.Mdb

???
Dangerous ?
Hugly ?

Mathieu

Jun 2 '06 #32

Mathieu Trentesaux

Albert D.Kallal a écrit :

as it's a matter of recognizing that

you can't ever edit the MDE, which was the original complaint, no?

Good point.....

In fact, it *seems* that a MDB was being used for the library code, and NOT
a mde. As mentioned, one *can* use a mdb, but I would strongly suggest that
a mde is used.

The library I was talking about is clearly (but not explicitely, I
admit) an Mdb database. This Mdb library have to be : 1°) edited, 2°) saved.

You can say its a bad way to make things, it won't change anything to
the problem : a theoretical approach can fail in front of a new reality.
Mathieu

Jun 2 '06 #33

> Dangerous ?

Hugly ?
Well, we live with what we've got. Repeatedly closing and
re-opening, renaming our files, switching between versions
to avoid crashes. It's ugly, but it works for us :~)

(david)

"Mathieu Trentesaux" <ma***************@free.fr> wrote in message
news:44***********************@news.free.fr...
david epsom dot com dot au wrote :
Our whole application is library code.

[...]
I need to work on and test library code.

[...]
I need to close Access after each test, so that I can
re-open Access to work on the code.

Before Access 1, I was working with Quick Basic (7,4,2) under Dos. Again
before QB I was working with Bascom86 plus an editor (Edix, Edlin) : the
problem we talk about brings me back to these ancients times... Test,
edit, compile...

Well david, I see that, at least, I'm not the only one having this
problem. What would you say about this kind of solution :

We make a button somewhere in Access which aim is to write each module of
the Library.Mdb in a new Access database named for instance Library.Tmp.
This button is done to replace the grayed save button.

When leaving Access, we launch a batch :
IF EXISTS Library.Tmp DEL Library.Mdb
IF EXISTS Library.Tmp REN Library.Tmp Library.Mdb

???
Dangerous ?
Hugly ?

Mathieu

Jun 5 '06 #34