"Versioning" a .MDB file

[Tony Toews]

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.

Oh, sorry, yes, but Aaron insists on stating ADPs are superior for
everything. Which they are not. They have their purpose in life but
their superiority is not at all evident.

I haven't worked with the A2003 installer and have no experience with
C# so I'm unable to answer your exact question.

How are you distributing updates? By using the runtime installer or
your own method? I'd suggest, as I think Arvin does, using your own
method once the initial version is on the client system by putting a
field in a table in the FE with the version number. Then, within
your app, interrogating the CD to see if it has a valid and newer MDB
on it. If so copy it.



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

 

[Dave]

Oh, sorry, yes, but Aaron insists on stating ADPs are superior for
everything. Which they are not. They have their purpose in life but
their superiority is not at all evident.

I haven't worked with the A2003 installer and have no experience with
C# so I'm unable to answer your exact question.

How are you distributing updates? By using the runtime installer or
your own method? I'd suggest, as I think Arvin does, using your own
method once the initial version is on the client system by putting a
field in a table in the FE with the version number. Then, within
your app, interrogating the CD to see if it has a valid and newer MDB
on it. If so copy it.

lets start again, this has gone way off base. the app is access xp, not
2003. it is packaged and installed by the packaging wizard. it must be
installed from a cd. the problem is that the packaging wizard's installer
needs a version that it can check, assuming of course that it can do that,
so that it doesn't ask the user about replacing an old file with the new
one. i am assuming that it asks because when an mdb file is used its
revised date is updated so the new file on the cd actually looks older.

 

[Rick Brandt]

lets start again, this has gone way off base. the app is access xp,
not 2003. it is packaged and installed by the packaging wizard. it
must be installed from a cd. the problem is that the packaging
wizard's installer needs a version that it can check, assuming of
course that it can do that, so that it doesn't ask the user about
replacing an old file with the new one. i am assuming that it asks
because when an mdb file is used its revised date is updated so the
new file on the cd actually looks older.

Why not just configure the installer to "replace always" and not worry about it?
That's what I have always done because I want to make sure a corrupted file is
replaced with a re-install. If you use "replace older files only" you run the
risk that this won't happen.

 

[Dave]

Why not just configure the installer to "replace always" and not worry
about it? That's what I have always done because I want to make sure a
corrupted file is replaced with a re-install. If you use "replace older
files only" you run the risk that this won't happen.

that would be an option, but where do you specify that in the office xp
packaging wizard?

 

[Rick Brandt]

that would be an option, but where do you specify that in the office
xp packaging wizard?

I have only used the Access 97 ODE for creating runtime installations, but in
that version of the setup wizard you can specify for every file whether it is
replaced Never, Always, or When Older. I assume that the newer versions have
the same options.

 

[Dave]

I have only used the Access 97 ODE for creating runtime installations, but
in that version of the setup wizard you can specify for every file whether
it is replaced Never, Always, or When Older. I assume that the newer
versions have the same options.

i sure don't see that in the xp wizard. where was it in 97??

 

[Rick Brandt]

i sure don't see that in the xp wizard. where was it in 97??

In the very first dialog where you list the files to be included in the
setup package. The options to be filed out are...

File Name and Path (to include)

Destination Folder

Overwrite Existing File (Older, Always, Never)

Component Name

 

[George Nicholson]

The 3rd(?) screen of my XP packaging wizard has a set of "Version number"
fields that can be filled in as you wish.

Are you sure that it isn't this info that is used to determine "oldest"
rather than file dates? I seriously doubt that a file date comparison is
used for the very reasons you specify: they are meaningless when dealing
with a mdb.

HTH,

 

[Dave]

i fill them in and increment with each installation package, but that
doesn't seem to affect the installation of them mdb file.

 

[Dave]

In the very first dialog where you list the files to be included in the
setup package. The options to be filed out are...

File Name and Path (to include)

Destination Folder

Overwrite Existing File (Older, Always, Never)

Component Name

sure don't see it... you can set if a files should be shared, but nothing i
can see about overwriting existing files.

 

[aaron.kempf]

Tony

you're a lying stealing piece of shit

it is true

i dont need your super code to be a super versioner.

I just use ADP and it's a LOT easier to deal with.

I have multiple version of stuff in DEV

APPNAME_20051019
APPNAME_20051020

if i need to make a new version in the middle of the day, i put a _8pm
at the end of it

pretty straight forward.

ALL OF THE COMPLEXITY OF VERSIONING MDB GOES AWAY WITH ADP

THIS GUY IS A SCAM!!!!

 

[aaron.kempf]

THE BOTTOM LINE IS THAT YOU HAVE 400kb FILES INSTEAD OF 50MB FILES.

SO YOU CAN AFFORD TO KEEP MULTIPLE VERSIONS

YOU CAN EMAIL ADP

YOU CAN DOWNLOAD ADP FROM A WEBSITE

pretty straightforward kids

 

[Dave]

THE BOTTOM LINE IS THAT YOU HAVE 400kb FILES INSTEAD OF 50MB FILES.

SO YOU CAN AFFORD TO KEEP MULTIPLE VERSIONS

YOU CAN EMAIL ADP

YOU CAN DOWNLOAD ADP FROM A WEBSITE

pretty straightforward kids

please, calm down. you are not talking about the same thing as the rest of
us. my problem is how to embed a version number in the mdb file being
distributed so that the installer doesn't ask the user the wrong question
about replacing a newer file. i have no size problem, nor do i have a
development problem, it is strictly about how to make the packaging wizard's
installer work properly.

 

[aaron.kempf]

i think that you do have a size problem and a development problem

and i think that that it's funny you guys sit around and version
databases all the time.

i dont have 2/3rds of the difficulties as you guys since i dont have to
version unless it's a change to a form or a report

i dont have to put out a new version since all my sprocs and views live
in one place. there aren't 100 copies of it.

i think that it is exactly the same discussion.

i mean-- there are no refreshing, no linking-- to dsn-- no connection
strings.. no queries that crap out.. there are no sql passthrough
queries

you can bind to a sproc

shit you can USE sprocs with ADP it is irrational to use sprocs in MDB
since it is too much complexity

 

[Tony Toews]

you're a lying stealing piece of sh*t

Umm, your response is just a little excessive, don't you think?

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

 

[Tony Toews]

please, calm down. you are not talking about the same thing as the rest of
us. my problem is how to embed a version number in the mdb file being
distributed so that the installer doesn't ask the user the wrong question
about replacing a newer file. i have no size problem, nor do i have a
development problem, it is strictly about how to make the packaging wizard's
installer work properly.

Dave

I'd strongly suggest ignoring Aaron's postings. Let him ramble on
his merry way.

I'll take a look at the MOD XP later today and do a bit of poking
about.

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]

Dave

I reccomend not listening to these Mvp-Mdb faeiries.

They need to start preaching the good word of ADP.

Half-- 2/3rds of the frequency of versioning can be avoided by choosing
the right architecture.

 

[aaron.kempf]

and technically-- the problem that you have is that people change
records it updates the filemodified time for the MDB file right?

well.. here you go buddy

when you open an adp and edit records; it doesnt change the
filemodified date for the .ADP file.. .

RIGHT???

 

[Karl E. Peterson]

and technically-- the problem that you have is that people change
records it updates the filemodified time for the MDB file right?

Sounds like a feature, to me.

well.. here you go buddy

when you open an adp and edit records; it doesnt change the
filemodified date for the .ADP file.. .

RIGHT???

LOL! What a POS... You're kidding, right?!? I wrote an application like that. It
memory-maps its datafiles for sheer performance, so the OS doesn't update timestamps
as their content changes. That's a bug, according (and rightly so!) to my users,
which I had to squash.

Watching your performance here, I'm really surprised your parents let you access
google. (Tired of all the nudie sites, huh?) How old are you, anyway?

 

[John Marshall, MVP]

Dave

I reccomend not listening to these Mvp-Mdb faeiries.

They need to start preaching the good word of ADP.

One of the MVPs strong points is that they are NOT evangelists.

John... Visio MVP