Revision Counts for Access Project

[IndianaJonesWB]

I have an Access Project as a front end for a SQL DB. I have a master
copy and distribute copies of it to my other users.

I would like to display a revision count on the first Main Form so that
when looking at the copies on other user's machines I can tell right
away if they are working with the latest version.

A Last revisied date would work too but it needs to be the last
revision or number of revisions to the front end itself.

[davidjpike]

Maybe you could drop a local table in the front end containing the
version number. Read this value from the table onto the main form, or
on opening the database assign it to a global variable.

If you need help with the above, post back as someone may have a better
answer.

Dave

[Bas Cost Budde]

da********@lycos.co.uk wrote:

Maybe you could drop a local table in the front end containing the
version number. Read this value from the table onto the main form, or
on opening the database assign it to a global variable.

That is exactly what I do and I'm very happy with the setup. As is my
customer. We're in a design cycle and this provides just the extra
control we need!

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
I prefer human mail above automated so in my address
replace the queue with a tea

[IndianaJonesWB]

How do I get the Revision Count into the local table? How does it get
updated?

[davidjpike]

Okay,

Before you go to release your next "front end" simply make a new table
maybe call it something like:

chkVersion - in this put one field, called whatever you want. (chk is
short for check).

Then stick in the version name/number.

The easiest (probably very slow but simple) way is then to place a
textbox onto your main form. Then use a dcount function to read the
value from your table.

There really are loads of different ways to do this, some of them a lot
better. But that should give you a simple start.

Does this help any?

When you send out your next front end, simply change the number in the
table you created above. That way the users will be able to see what
version the software is.

Dave

IndianaJonesWB wrote:

How do I get the Revision Count into the local table? How does it get updated?

[Bas Cost Budde]

IndianaJonesWB wrote:

How do I get the Revision Count into the local table? How does it get
updated?

I do it manually. If you want some automation, you have to *very
carefully* consider what you call a revision, and under what
circumstances you want such an update.

I tried and came up with so many afterthoughts and doubts that I didn't
bother, and wrote a small routine that updates the revision number, and
outputs the objects changed since the last revision to a log file.

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
I prefer human mail above automated so in my address
replace the queue with a tea

[IndianaJonesWB]

I was looking for something more automatic.

Basically any change to the ADP configuration should trigger a change
to the Revision Count or Version or whatever. But the DateLastModified
changes whenever the database is opened, so that doesn't seem to work.

[Bas Cost Budde]

IndianaJonesWB wrote:

I was looking for something more automatic.

Basically any change to the ADP configuration should trigger a change
to the Revision Count or Version or whatever. But the DateLastModified
changes whenever the database is opened, so that doesn't seem to work.

Automatic... trigger... I recognize that.

What about the good old hidden form approach, the one that closes last
when you exit Access? That would be a moment to decide whether to note a
new revision.

The question, or rather decisions, about what exactly constitues a new
version still remains. Count of objects changed? Compile All disturbes
that. Number of controls, or lines of code? Quite intensive, and maybe
an inaccurate measure.

What do you think?

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
I prefer human mail above automated so in my address
replace the queue with a tea

[IndianaJonesWB]

Doesn't it seem like Micorsoft would keep track of changes to the ADP
file's Configuration in one place? Like a Checksum or CRC for the
file.

Why would the DateLastModified change when the file is simply opened
and closed? In an ADP File there's no real data. It's just a front
end.

Apparently this isn't straightforward (unless I'm missing something
obvious).

I've done front ends for other things (like with WonderWare) and they
keep track of revisions. What a pain!

[Larry Linson]

<da********@lycos.co.uk> wrote

Maybe you could drop a local table
in the front end containing the
version number. Read this value from
the table onto the main form, or
on opening the database assign it
to a global variable.
Access Projects (ADP/ADE) don't _have_ "local tables". That is one of
several reasons I use Access Databases (MDB/MDE) instead, whenever it is my
choice. For MDB/MDE, your suggestion is a good one.

You could put the "local" version number in a label on a Form, though.

Larry Linson
Microsoft Access MVP


If you need help with the above, post back as someone may have a better
answer.

Dave

[Larry Linson]

"IndianaJonesWB" wrote

I was looking for something more automatic.

I cannot imagine not having manual control of "releases" and "versions"
unless it is for Source Control, in which case, I'd be using packaged Source
Control software, not writing my own scheme. And, because it has been a
long, long time since I worked on a project of sufficient scope to require
automated Source Control*, I can't make a specific recommendation -- other
than to say that the Developer Edition includes Visual Source Safe (but, if
memory serves, the Visual Studio Tools for Office 2003 System does not, so
you'd have to license VSS itself separately).

* that was in 1994, long before VSS, and they
used a third-party product that worked passably
well, but which ceased to be produced in the
Access 95/97 timeframe.

Larry Linson
Microsoft Access MVP

[IndianaJonesWB]

Manual control of the version number seems to be my only alternative.

For now I have a label on my main form with a number I have to remember
to update whenever I change the front end.
I'm kind of afraid I'll forget but I guess it's the best way to do it.

[Larry Linson]

"IndianaJonesWB" wrote

Manual control of the version number
seems to be my only alternative. For
now I have a label on my main form
with a number I have to remember to
update whenever I change the front end.
I'm kind of afraid I'll forget but I guess
it's the best way to do it.

Because we had a small team, we alternated "release commander" duties on a
project with which I was associated for five years or so. We were releasing
/ publishing new releases and versions to the users, not tracking
development with release/version, but not once in those five years did any
of us forget to update the version and release, and the corresponding latest
available and mandatory version and release in the server database.

But, each of us used the same checklist... it started with 12 separate
steps, and grew over time to 18 or 19, for the things we did to ready and
publish the new release. Of course, one of those steps dealt with updating
the version in the front end (in our case, it was an MDB, and that
information was in a local table) and another with updating the two
version/release indicators in the server database. A few more details on our
approach are in an article at http://accdevel.tripod.com.

We did NOT use these versions to track development changes. We defined the
development work to be done on each release, assigned tasks to individuals,
and tracked the tasks. As you might guess, we had separate development and
production databases... when the work for a release was complete, we backed
everything up, and "promoted" the tested development copy to production
status. Because we had a significant chain of backups, we could easily
revert to an earlier version/release if something went wrong.

Larry Linson
Microsoft Access MVP

Larry Linson
Microsoft Access MVP

[IndianaJonesWB]

Just though I'd give an update to this string.

What I did was use some code to put a version ID on the main form. I
update this Version ID Manually.
Then I created a table on SQL Server with each Version and a
description of what I did for that version.

When the main form opens up it compares the local value of my custom
Version to the lates version in my table. If they don't match the user
is prompted to get an update.

The user is also warned if he attempts to open the database from the
master copy of the front end. (This allows me to post a new version
without worrying about sharing violations).

It really works pretty good.

Heres the code in my main form:

Private Sub Form_Open(Cancel As Integer)
Dim fs, f
Dim MyVersion As String
Dim rst As New ADODB.Recordset
'On Error GoTo Form_Open_Error
MyVersion = "01-07-2005 1.8"

Set fs = CreateObject("Scripting.FileSystemObject")
Set f = fs.GetFile(CurrentProject.FullName)

If f.Path = <Master File Name> Then _
MsgBox "You've opened this Database from the I:\xxx\xxx directory"
& vbNewLine & _
"Please Close this database and copy 'xxx.adp' to your
desktop!"

rst.Open "select top 1 * from dbo.rnc_db_revs where
isnull(revnumber,'')<>'' order by revid desc",
CurrentProject.Connection,
adOpenForwardOnly, adLockReadOnly
If rst!RevNumber <> MyVersion Then _
MsgBox "Check your Revision Level!!" & vbNewLine & _
"Latest Rev is: " & rst!RevNumber & vbNewLine & _
"This Rev is: " & MyVersion & vbNewLine & _
"To Update Close this database;" & vbNewLine & _
"Copy 'xxx.adp' from the I:\xxx\xxx Directory to your
desktop" & vbNewLine & _
"Open 'xxx.adp' from your desktop"
rst.Close

Exit Sub
Form_Open_Error:
MsgBox "Error Connecting" & vbNewLine & "Call R&C Database
Administrator"
End Sub