"Versioning" a .MDB file

[Jeffery Tyree]

A friend is developing a Access 2003 database. I am developing a simple
installer package using C#Net. We are looking for best methods, suggestions
and definately code examples for:

1. Setting a 'version number' type property of the Access .MDB/.MDE file
within Access/VBA

2. Then how to read the.MDB/.MDE's 'version number' from C#.Net

TIA
-Jeff

 

[aaron.kempf]

why dont you just put a version number in a table or something?

then if you want; on the VBA side ThisVersion = DLOOKUP("CURRVER",
"VersionInfo")

-aaron

 

[Dave]

how about a hard question? how do you version an access xp file so that the
office xp developer packaging wizard installer knows to replace an older
version mdb file instead of asking the user about replacing an existing one
with an older one from the installation package??

 

[Dirk Goldgar]

A friend is developing a Access 2003 database. I am developing a
simple installer package using C#Net. We are looking for best
methods, suggestions and definately code examples for:

1. Setting a 'version number' type property of the Access .MDB/.MDE
file within Access/VBA

2. Then how to read the.MDB/.MDE's 'version number' from C#.Net

You can set a custom database property, which is very easy to do via the
Access user interface: File -> Database Properties, Custom tab.
However, the only way I know to read that property is with DAO, and I'm
not sure whether that's an option for you or not.

*VBA* DAO code would look like this:

Dim db As DAO.Database
Dim sngAppVersion As Single

Set db = DBEngine.OpenDatabase("YourPath\YourDatabase.mdb")

sngVersion =
db.Containers("Databases").Documents("UserDefined").Properties("AppVersi
on")

db.Close

It may well be simpler to use a field in a record in a table, as Aaron
Kempf suggests.

 

[Jeffery Tyree]

Thank you for the suggestion Aaron. However, I would like to avoid database
access by the installer.

It will be the installer application (C#Net) that will be concerned with
reading the .MDB/.MDE version number and then decide what type of
install/upgrade to do based on the version number. Preferably we would
like to use the properties or something similar like you see on the
'Version' tab when you do a 'Properties' select on an .EXE file from the OS
side but this tab does not seem to be available when doing a 'Properties'
select on a .MDB/.MBE file.

-Jeff

 

[aaron.kempf]

can't you just put a version number in the file name?

I just personally can't stand the package and deployment wizard.. i
mean for starters-- its' total overkill for a simple app via the Access
runtime

i'd just reccomend storing it in the database. and pulling it out.

if your c# SHIT can't pull a value out of a database; then why dont you
just write an MDB to help you with deployment?

i mean seriously.

Why dont you just use a MDB instead of PND and C# and all this other
crap. i mean-- all you're doing is pushing a file from one location to
another.. right?

 

[Arvin Meyer [MVP]]

My database starter has a versioning module in it. Just open it, and copy
the routines:

http://www.datastrat.com/Download/Starter.zip
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[Dave]

does that work with the packaging wizard's installer to properly identify
the revision of the mdb to avoid asking the user which one to use??

 

[Gary L. Chefetz [MVP]]

Jeffery:

Please don't cross-post all over the place.

 

[Kjell]

I would use custom properties on the db object

I'm not 100% sure how it works in ADO, but in DAO it work fine....

Use the CreateProperty function on the open database to once and for all
create your custom property, for example a string value.

After that you can read and write to the property just by assigning new
values to it, of course you'll need to open the db object, but you do not
need to open any table.
for ex.
DB.properties("YourPropName").Values = "56589"
if clng(DB.properties("YourPropName").values) > 50000 then ....


Kjell

 

[Arvin Meyer [MVP]]

It creates a custom property named "Version" and fills the value. The other
code allows reading the version property and changing the version property
to a different value. The rest of the app deals with downloading a copy from
the server if the version is different than the one on the workstation.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[Dave]

sorry, i don't have that luxury. this must be delivered on a cd for
installation. but the way the installer included by the packaging wizard
works it apparently only checks the modified date, which if the user has
been using their copy can be later than the date on a newer version file
being delivered... this of course causes the installer to ask if they want
to replace their 'newer' file with an 'older' one from the installation,
which is of course confusing. so, the question remains i guess... is there
some way to set the version in an mdb file so the packaging wizard's
installer knows the revision so it doesn't ask the user about replacing the
file?

 

[George Nicholson]

but the way the installer included by the packaging wizard works it

apparently only checks the modified date,

Really? I thought the XP packaging wizard checked the version number on the
3rd screen ("Application Information") of the packaging wizard. I guess I've
just been incredibly lucky. (I'm not being sarcastic, i really mean I guess
I've been incredibly lucky)

--
George Nicholson

Remove 'Junk' from return address.

 

[Arvin Meyer [MVP]]

Excessive crossposts have been trimmed.

The code I use in my sample only checks to see that the 2 versions are
different. It doesn't care what the difference is, nor does it care about
dates.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[Dave]

yes, but you state your code goes and downloads something from a server if
it needs an update... that is not an option. i am looking for how to embed a
revision such that the installer that the packaging wizard makes can check
revisions properly when updating an installation.

 

[aaron.kempf]

what you should do is:

a) use ACCESS DATA PROJECTs instead of MDB
b) not worry about versioning tables and queries

that's why you should do

 

[Tony Toews]

what you should do is:

a) use ACCESS DATA PROJECTs instead of MDB
b) not worry about versioning tables and queries

that's why you should do

Your reply is nonsense in this context. How do you distribute a new
ADP which has new features?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[aaron.kempf]

then you dont need to version as often

with MDB you have to version all sorts of crap all the time

with ADP; you keep all your queries and tables in one place; so
versioning becomes abotu 10 times easier.

queries and tables are all that changes in an app.. the frontend is
easy.

how do i distribute ADP?

I make a webpage for people to download them from. They're small--
they're not 200mb like most Access MDBs.

Or i've done batch files with AD in order to push them out

I just swear-- most of the complexity in versioning MDBs just gets
thrown out the window when you start using a real app.. like ADP for
example.

 

[Dave]

i have already split the mdb to front and back, it is the front end updates
that i need to have installed from a cd without the user having to figure
out if they want to keep their old one or install the new one. as i have
stated, downloads and installs from web are not an option. and my problem
is not with how to check or control versions of tables and queries, that is
all taken care of internally, it is the packaging wizard's installer that is
the thing that has to be able to check versions.

 

[aaron.kempf]

do you work for a winery in seattle?

just checking