Visual SourceSafe: Anybody Used It For An MS Access Project

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?

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" wrote in message
...
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?

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?
--
PeteCresswell

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.

"PeteCresswell" wrote in message
...
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?

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)" wrote in message
...
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?
--
PeteCresswell

On Oct 28, 4:22 pm, "Klatuu" wrote:
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.

On Oct 29, 2:11 pm, PeteCresswell wrote:

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"

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" wrote in message
...
On Oct 29, 2:11 pm, PeteCresswell wrote:

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"

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....
------------------------------------------------------------

--
PeteCresswell

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)" wrote in message
...
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....
------------------------------------------------------------

--
PeteCresswell