Visual SourceSafe: Anybody Used It For An MS Access Project

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

"(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?
--
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?

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?

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

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