Visual SourceSafe: Anybody Used It For An MS Access Project

[PeteCresswell]

They just threw another programmer at me - along with the requirement
that we use Visual Source Safe to manage our respective areas of
endeavor.

Anybody use it?

Warm fuzzies? Bad vibes?

 

[Paul Shapiro]

I like it as a single developer. Been using it for years. Sourcesafe has a
reputation for being susceptible to corruption, so be careful about backing
up the Sourcesafe database (which is a very large collection of files, and
not a real database). I've never had serious problems with it. It's free
with my MSDN subscription, so I haven't investigated alternatives. I use it
for my own privately-used databases too, not just those developed for
clients.

I love the complete history of every change you ever make. When a client
tells me something stopped working, I can reliably see every change to the
code. Or the fact that nothing has changed in that part of the code in 3
years, so something else is the issue. Sourcesafe lets you apply a label to
the entire code at a point in time. I label every customer release, which
makes the history tracking easy.

I like being able to share forms and modules across databases, using
Sourcesafe's sharing. I can edit the code in any of the databases, and it
will be updated in the others the next time I build the db from Sourcesafe.
I use this for my standard error-handling code and form, and for my
library-type code. It's nice not having to remember to fix the same bug or
make the same enhancement in different databases.

I like the fact that if your Access db is corrupted, you just build a new
copy from Sourcesafe. I tend to check work in frequently, so I don't lose
much if the Access db does get corrupted. In earlier Access versions, using
Sourcesafe seemed to increase the corruption likelihood, but I don't see a
problem in Access 2007 and I don't remember issues in 2003. The one issue I
do remember is that a sourcesafe-integrated database sometimes had huge
problems when developing in Access 2003 and deploying in Access 2007. If
that's your situation, let me know and I'll send you the workaround lists.
Now I develop in Access 2007 and deploy in either 2007 or 2003 without
problems. No sourcesafe issues. Before deployment, you compact & repair the
db. Each time you compact & repair a sourcesafe-integrated db, Access asks
if you want to remove the sourcesafe integration. For deployment, say Yes.
If I'm deploying in Access 2003, I open the db in a virtual machine running
Windows XP and Office 2003 (the oldest software any of my clients are using)
to adjust the code references.

Depending on your Access version, hunt on Microsoft's website to find the
Access-Sourcesafe integration components. They used to cost money, but
they've been free since Access 2003.

 

[(PeteCresswell)]

Per Paul Shapiro:

. The one issue I
do remember is that a sourcesafe-integrated database sometimes had huge
problems when developing in Access 2003 and deploying in Access 2007. If
that's your situation,

Not yet - and probably if we go 2007, I'd convert one time and
stay w/2007.

Right now, I use the front end's name as part of my versioning
scheme. SfimApp.273.mdb is version 2.73. SfimApp.274.mdb is
2.74.

Safe to say that this scheme is about to go out the window?

If so, how do you deploy if the old version's file name is the
same as the new one? I'm currently using a .BAT file that
parses a Version.txt and copies the latest-and-greatest to the
user's C: drive.

I guess I could build from VSS into SfimApp.mdb, and then rename
it to SfimAppl.275.mdb before elevating - but maybe greater minds
than mine have a more elegant solution..... like maybe a
dedicated app to replace the .BAT file that looks into the .mdb's
props?

 

[Klatuu]

Paul pretty much said it all. There is one thing to note, there is a
utility you need to download if you are using VSS with Access, but it has
been so long, I'm not sure where it is anymore. Some where in the vast
laberynth of Microsoft or MSDN.

As to keeping version separate, I find the easiest method is Labeling. Just
read up on it in VSS Help.

 

[Paul Shapiro]

I deploy to clients with the same file name each time. The current front end
db sits in a share on their server. The user runs the app by executing a
batch file which always copies the current FE to the local computer and then
executes it. This takes care of upgrades and any corruption or bloating by
starting with the latest clean FE each time they run. The extra time to copy
the FE across the network is insignificant.

But it's not a big deal either if you want to rename the FE before
distribution. You have to make an "extra" copy anyway to compact & repair to
remove the sourcesafe properties before distribution. Otherwise the user
gets a warning that SourceSafe is not available.

If I'm doing the installation I keep copies of the older FE's in an
OldVersions subfolder of the current installation. I usually distribute the
FE in a zip file, and I give each zip file a custom name with the version
number. If the client does the installations, I recommend they also keep the
old FE zip files. In any case, I keep copies of all released versions on my
own system.

When I'm ready to convert a db to a new Access version for development, I
check out everything from Sourcesafe. Then close the db and open it with the
new Access version. After making sure everything looks good, check
everything back into SourceSafe. Now you should be able to create a new db
from SourceSafe using the new Access version.

 

[PeteCresswell]

Paul pretty much said it all. There is one thing to note, there is a
utility you need to download ....

Thanks. I'm chasing it down right now.

In addition to the util, can anybody think of any Access-specific ins-
and-outs?

e.g. Do we "check in" the entire front end .mdb and let SourceSafe
slice and dice it?

Or do we break it up ourselves and check it in piece-by-piece? e.g.
each basic module, each form, each screen, and so-forth.

 

[PeteCresswell]

Thanks. I'm chasing it down right now.

In addition to the util, can anybody think of any Access-specific ins-
and-outs?

I suspect the "utility" answers that question.

Seems tb an MS Access add-in called "the Access Source Code Control"

 

[Paul Shapiro]

That's correct. Just make sure you get the version for your Access version.
Last time I looked they don't make it so easy to find. Before installing the
Access-specific utility you need to install SourceSafe on the server and
create a SourceSafe database. Then you can install the SourceSafe client on
your workstations. Last step is installing the Access add-in.

I only add the front-end db to SourceSafe, not the backend. Not much point
to controlling the backend because all the tables and their data are stored
as one big binary blob in SourceSafe. You can't see any change info.

When you're first adding a new db to SourceSafe, there's a menu item in
Access to Add DB to Sourcesafe. The integration utility automatically
extracts each form, query, report and module as text files and adds them to
the SourceSafe project. There is a single binary chunk for the linked
tables, references, etc. There's one cryptically named file whose only
purpose is to tell SourceSafe what name to give to the db when it creates a
new one from the SourceSafe project.

When you open any Access item in design mode, you get a prompt asking if you
want to check it out of SourceSafe. If you want to save your changes, answer
Yes. When you're finished you can right-click the object in the db window
and choose Check-In. I usually add a comment indicating the changes. You can
get reports of those comments or just review them if you're later looking to
see what changed. The SourceSafe Explorer also lets you get a list of all
saved versions of an object, and compare any 2 versions with changes
highlighted.

 

[(PeteCresswell)]

Per Paul Shapiro:

When you're finished you can right-click the object in the db window
and choose Check-In. I usually add a comment indicating the changes.

What does one do when they want to pass a copy of the app to
another developer?

Zip up the file from one's own drive with the VSS-specific stuff
in it and sent it to the other person?

I finally got a version of the app to load into VSS on the fourth
try.

If anybody else is going to do this, here's what I've discovered
so far:
---------------------------------------------------------------
1) Objects whose names begin with "$" must be deleted or renamed

2) Any links to non-existent tables must be deleted. e.g.
work tables which get created on-the-fly, but whose
links stay on after the work db is deleted.
---------------------------------------------------------------


Next steps for Yours Truly:
------------------------------------------------------------
1) Do a build from the version I've got loaded right now.

2) Test that build to make sure it has all it's functionality.

3) Figure out how to make a change to the build, then save the
change.

4) Re-build and see if the change sticks.

5) Figure out how to maintain parallel versions. e.g.
we're working towards a big release sometime next month,
but the users want a small change to the existing production
version. This seems like a biggie to me....

 

[Paul Shapiro]

Once the db is added to SourceSafe, each computer where you want to do any
development has to run the Create DB from SourceSafe utility to create their
own local sourcesafe-integrated copy of the db. If you move a db to another
computer, or even another folder on the same computer, Access disables the
sourcesafe integration.

I found performance was significantly better when I work with the db on my
local drive and not on a network drive. The "backup" is the SourceSafe data
on the server.

When creating the db from SourceSafe, the backend db needs to be available
or the linked tables are removed. I don't remember if it's necessary, but I
keep an empty copy of the backend db in the local folder where I have the
sourcesafe-integrated front end db.

The default setting is to always get the latest object version from
SourceSafe whenever you check it out for editing. So if you've updated a
form and another developer wants to use the latest version of that form
after you've checked it back in, they just have to check it out for editing
and then check it back in. There is a context menu item to Get Latest
Version, which would avoid the check-out/check-in cycle, but I don't
remember that working correctly. I developed habits from working with older
Access versions, so maybe it works correctly now.

When I'm ready to distribute a version to a client, I rename and save the
development db and then create a new "virgin" db from SourceSafe. I make a
copy of that for distribution, and remove the sourcesafe integration from
that copy. The original becomes my development db. This accomplishes what
the /decompile switch used to, removing any orphaned bloat.

The parallel versions bit is complicated. SourceSafe does have support for
branching projects, and later merging the changes back to the main code, but
I've never used it and I don't know if it works correctly with Access.
You'll have to do some reading and experimenting for that. I always release
from a single code base.

 

[(PeteCresswell)]

Per Paul Shapiro:

When creating the db from SourceSafe, the backend db needs to be available
or the linked tables are removed.

Sounds like a change to my reconnect code is in order.

Right now, the code requires an existing connection tb there for
it to check and update. Gotta change it so that it creates a
new connection if there's none there - or maybe just deletes any
existing one before unconditionally creating a new one.

That's almost how my "WorkTable_Create()" routine works: blows
away any existing link and creates a new one.

Otherwise, we'd be getting burned every time the app was built
out of VSS onto a PC that had the back end in some other
directory than the SourceSafe's version.

In fact, now that I'm thinking about it, the right way for me to
load the app into SourceSafe in the first place is to delete
*All* links before loading and let the code re-establish them as
needed.

The branching thing *is* a biggie then.... and that's the whole
rationale for IT forcing us to use SourceSafe: multiple
incremental changes to the production version while a major
release is evolving concurrently.

 

[lij]

Per Paul Shapiro:

Not yet - and probably if we go 2007, I'd convert one time and
stay w/2007.

Right now, I use the front end's name as part of my versioning
scheme. SfimApp.273.mdb is version 2.73. SfimApp.274.mdb is
2.74.

Safe to say that this scheme is about to go out the window?

If so, how do you deploy if the old version's file name is the
same as the new one? I'm currently using a .BAT file that
parses a Version.txt and copies the latest-and-greatest to the
user's C: drive.

I guess I could build from VSS into SfimApp.mdb, and then rename
it to SfimAppl.275.mdb before elevating - but maybe greater minds
than mine have a more elegant solution..... like maybe a
dedicated app to replace the .BAT file that looks into the .mdb's
props?

 

[PeteCresswell]

Branching Strawman:
-------------------------------

Sounds to me like a little branching goes a long way.

e.g. Programmer A and Programmer B.

We already have Branch_Root.

Now we create Branch_A and Branch_B.

Both programmer A and B have changes to make on frmSecurity.

They can each check out the form concurrently based on their branches.

Programmer A checks frmSecurity out from Branch_A.

Programmer B checks frmSecurity out from Branch_B.

Each one makes their changes, tests same, and checks their respective
version of frmSecurity back into their branch.

At some point in time, we need to merge Branch_A and Branch_B back
into Branch_Root.

Probably a two-stage process:
- Merge Branches A & B into Branch_Temp
- Merge Branch_Root and Branch_Temp

At merge time, VSS is going to recoginze that frmSecurity.BranchA
differs from frmSecurity.BranchB and give us a list of the diffs -
probably with an option to either let VSS resolve them or have us
resolve them manually.

I'd guess having VSS resolve them is one of humanity's original Bad
Ideas.

So, now we're sitting down at a PC and reviewing the differences on a
line-by-line basis and choosing some from Branch_A and some from
Branche_B...... and here's where "A little bit goes a long way" comes
into play - bc each decision affects how the merged version works.

Wrong decision, broken application.

Have I got any of this right so far?

 

[PeteCresswell]

Things are going pretty well.

Got the app into VSS in several stages - each one a mirror of a
production release and each one labeled.

But now, just for GPs, I want to build from a label. i.e. go back a
couple of releases and build that release.

Not getting anywhere.

People I'm working with are pretty sure it's done routinely in a .NET
scenario - but they're coming up blank too w/Access.

Is it possible in an Access scenario?

 

[Paul Shapiro]

I've never tried to do it, so I don't know. By default VSS enables
"cloaking" for an Access project. I seem to remember you get some more
options in the VSS shell if you disable cloaking for the project. I believe
the VSS shell will let you get all the files for a label into your working
folder, or maybe you can specify the folder. The difficulty would be getting
Access to build from that folder without getting the latest versions from
VSS. That may be a VSS project setting once you disable cloaking. You could
write your own code to loop through all the files in that folder using the
LoadFromText function, but I've never tried.

There may be another catch though. By default, I think the binary blob that
Access shows as Data and Miscellaneous Objects only keeps the latest
version. So the older version doesn't exist anymore.

 

[(PeteCresswell)]

Per Paul Shapiro:

By default, I think the binary blob that
Access shows as Data and Miscellaneous Objects only keeps the latest
version. So the older version doesn't exist anymore.

That was the only part of VSS that really disappointed me:
keeping all that stuff as a single blob.

Found a few bugs - but they smell more of a missing service pack
or something..... OTOH the blob-for-everything-that-doesn't
readily export-to-text smacks of accountants running the show.