Re: My ritual question for each new version of Access since 2000

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" <PleaseNOOOsPAMmkallal@xxxxxxx> wrote in message
news:cGTfg.222201$P01.112446@xxxxxxxxxxx
"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:447f9a3d$0$96807$c30e37c6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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
pleaseNOOSpamKallal@xxxxxxx
http://www.members.shaw.ca/AlbertKallal



.

Relevant Pages

  • Help needed: Access & Visual Source Safe
    ... leverage our Visual Source safe 6 repository for version control. ... I also first made sure that VSS was patched with the latest service ... i went to tools and added my database to VSS ... everything but my forms and reports in it. ...
    (microsoft.public.access.devtoolkits)
  • Re: Database change management process
    ... plus VS and Visual Source Safe costs an assload. ... your other environments via a controlled process (i.e. DBA applies database ... processes of change control for sql server databases and so on... ...
    (microsoft.public.sqlserver)
  • How do I give ASP.NET process network credentials?
    ... Source Safe database is not a database in the traditional sense of the word. ... VSS API in order to access the VSS database on dimension. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: How do I give ASP.NET process network credentials?
    ... > I have a Source Safe database installed on my Win2K 'domain controller'. ... > VSS API in order to access the VSS database on dimension. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • RE: Source control to Access 2002
    ... Have you added your database to ... Source Safe first? ... I have not used VSS with Access for a ... objects file nor a database name ...
    (microsoft.public.vstudio.sourcesafe)