package application/ future updates

Will this be answered in the Dev Edition?

The dev edition does not address the issues of updates any more then what
you have now.

In other words, you current development practices for the most part must
include this issue. It is not solved the dev edition.

In fact, if you adopted good development practices, then using the runtime
edition of ms-access will not be a lot of work.

For example, for a good many years I always built a nice custom interface,
and hide all of the ms-access stuff. You will have done this long before
using the runtime (we hope!!). If you not been hiding all of the ms-access
interface now, you should start doing this. When you finally get around to
using the runtime edition, then NO additional work will be required. Here is
some screen shots of a ms-access application. Note how all of the ms-access
stuff is hidden.

http://www.members.shaw.ca/AlbertKal...erFriendly.htm

Since the runtime does not have all of the ms-access menus, you need to
provide the features you need by building your own forms, or often some
custom menus.

So, you most certainly can, and should hide all of the ms-access interface.
The options to complete hide and keep people out of the ms-access interface
can easily be done using the tools-start-up options. Using those options
allows you to complete hide the ms-access interface (tool bars, database
window etc). Also, using these options means you
do not have to bother setting up security.

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKal...s/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:
http://www.members.shaw.ca/AlbertKal.../msaccess.html

The above example would be "runtime" ready.

I can see updates/revisions that can be done to improve performance and
add
extra features, but want to do this at a later date.

Adding new reprotes, new forms, bug fixes in code.....adding new code is all
very easy. It is assumed that you split your database. Thus, to udpate a
user to the next great version of your product, you simply send them a new
front end (which by the way *should* be a mde --- this begs the question
now..you should as a habit be using and deploying mde fiels now in
preopfartion for the day when you start using the runtime -- so, get used
this concpet now).

If you not been working with a split data base..then this is another issue
that you need to become 2nd nature to your develpumet process. Here is a
article on splitting

http://www.members.shaw.ca/AlbertKal...plit/index.htm

So, splitting your database will make updates very easy. Remember, even
with the runtime/dev edtion, any mdb, or mde file you palce on that comptuer
will fucntion by simply double cliking on it. The runtime is nothing
speical..but simply a edtion without the desing part...the rest of how it
works is really the same as the full edtion (snas the menus).

Added features meaning
additional tables will be needed for different data type.

ok..now we are talkbing about modfyingt the tables and data...and NOT just
hte code. This is a more dififcult issue.

There are seveal apprahces here

** Simply have the user send you back the data file...you mdofy
it..and send it back to them. This kind of aporach is not very good, but if
you think about it..it is likey what you been doing now. (you make sure no
one is using the database..and then you simply mdoify it).

** write code to deteict that the particlar table, or field is
missing..and then write more code to "add" this table, or field to the back
end database. THis takes code, and is more effort on your part..but certanly
less work on the end users part. This is much like what happens when a new
verstion of word, or even ms-access comes out....some tables and interal
things have been modifed...so you have a new format. Hence, you can offer
some coverter program you write..but for the sake of simplicy, you startup
code in the apcpaton shoul djust for these msising fields..and then you
write code to add those fieds or tables to the database.


Can I package an updated version?

I actually don't use the package wizard to send updates. I just zip the new
mdb, and send them a self extracting zip file. I done this for years. It is
far easier then trying to use the package wizard for this.

Note that the runtime system is really more of a purchase of the *right* to
distribute your application. However, as a application install system, it is
very weak. If you are planning wide spread installs to machines that you
don't have control over, then I would suggest that you consider purchasing
some 3rd party scripts...such as those from

www.sagekey.com


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Albert, Thank you for clearing some things up. I now know for sure that I am
heading in the right direction.

As of right now. My application (beta) is running on my company's network.
I split the database as was mentioned in your review, and have the frontends
as .mde(s). It is a replicated copy, which is easy to make different updates
as far as satisfiying everyones needs.

Our other branch office is now looking into bringing my product on board.
But they are wanting just a "stand alone" version. So I am thinking of not
splitting it and making it a replica as well.

As for custom menus, I know that is one area that I need work on...I have
used the start-up option to hide everything but one menu provided by access.
I have been putting on paper, what would seem to me, is an easy flow....

I am using the link table code from mvps.org to make it easier to relink
tables. And know that it will be fairly easy to send an updated version of
the frontend.

Now the problem I am facing with updating/adding tables. The business I am
in (insurance) is a highly competitive/niche group. All our policies are
subsidized by the Feds. Hence - I am in direct competition with people that
would be using my program. I do not think I could get them to zip me the
backend since I will then have all contact info on their customers.

So I have tring to get code whereby I can update the backend. Ken Sheridan
was kind enough to provide an ExplodingParts Function...I guess right now
thats a little above my head I can not seem to get it to work. It is he

http://www.microsoft.com/office/comm...2-a0e8324d228e

I have read some of your replies while searching on google groups and have
been playing around with Inno, as an installer.

Thank you, I have really enjoyed reading your responses to everyone and
reading on your site. I just wish I had half your knowledge.

Gerald



"Albert D.Kallal" wrote:

Will this be answered in the Dev Edition?

The dev edition does not address the issues of updates any more then what
you have now.

In other words, you current development practices for the most part must
include this issue. It is not solved the dev edition.

In fact, if you adopted good development practices, then using the runtime
edition of ms-access will not be a lot of work.

For example, for a good many years I always built a nice custom interface,
and hide all of the ms-access stuff. You will have done this long before
using the runtime (we hope!!). If you not been hiding all of the ms-access
interface now, you should start doing this. When you finally get around to
using the runtime edition, then NO additional work will be required. Here is
some screen shots of a ms-access application. Note how all of the ms-access
stuff is hidden.

http://www.members.shaw.ca/AlbertKal...erFriendly.htm

Since the runtime does not have all of the ms-access menus, you need to
provide the features you need by building your own forms, or often some
custom menus.

So, you most certainly can, and should hide all of the ms-access interface.
The options to complete hide and keep people out of the ms-access interface
can easily be done using the tools-start-up options. Using those options
allows you to complete hide the ms-access interface (tool bars, database
window etc). Also, using these options means you
do not have to bother setting up security.

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKal...s/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:
http://www.members.shaw.ca/AlbertKal.../msaccess.html

The above example would be "runtime" ready.

I can see updates/revisions that can be done to improve performance and
add
extra features, but want to do this at a later date.

Adding new reprotes, new forms, bug fixes in code.....adding new code is all
very easy. It is assumed that you split your database. Thus, to udpate a
user to the next great version of your product, you simply send them a new
front end (which by the way *should* be a mde --- this begs the question
now..you should as a habit be using and deploying mde fiels now in
preopfartion for the day when you start using the runtime -- so, get used
this concpet now).

If you not been working with a split data base..then this is another issue
that you need to become 2nd nature to your develpumet process. Here is a
article on splitting

http://www.members.shaw.ca/AlbertKal...plit/index.htm

So, splitting your database will make updates very easy. Remember, even
with the runtime/dev edtion, any mdb, or mde file you palce on that comptuer
will fucntion by simply double cliking on it. The runtime is nothing
speical..but simply a edtion without the desing part...the rest of how it
works is really the same as the full edtion (snas the menus).

Added features meaning
additional tables will be needed for different data type.

ok..now we are talkbing about modfyingt the tables and data...and NOT just
hte code. This is a more dififcult issue.

There are seveal apprahces here

** Simply have the user send you back the data file...you mdofy
it..and send it back to them. This kind of aporach is not very good, but if
you think about it..it is likey what you been doing now. (you make sure no
one is using the database..and then you simply mdoify it).

** write code to deteict that the particlar table, or field is
missing..and then write more code to "add" this table, or field to the back
end database. THis takes code, and is more effort on your part..but certanly
less work on the end users part. This is much like what happens when a new
verstion of word, or even ms-access comes out....some tables and interal
things have been modifed...so you have a new format. Hence, you can offer
some coverter program you write..but for the sake of simplicy, you startup
code in the apcpaton shoul djust for these msising fields..and then you
write code to add those fieds or tables to the database.


Can I package an updated version?

I actually don't use the package wizard to send updates. I just zip the new
mdb, and send them a self extracting zip file. I done this for years. It is
far easier then trying to use the package wizard for this.

Note that the runtime system is really more of a purchase of the *right* to
distribute your application. However, as a application install system, it is
very weak. If you are planning wide spread installs to machines that you
don't have control over, then I would suggest that you consider purchasing
some 3rd party scripts...such as those from

www.sagekey.com


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

As of right now. My application (beta) is running on my company's
network.
I split the database as was mentioned in your review, and have the
frontends
as .mde(s). It is a replicated copy, which is easy to make different
updates
as far as satisfiying everyones needs.

The above seems to have a issue here that is not right. You NEVER want to
use replication for updating your front ends.
Replication is for data..not forms. I can't imagine any successful setup
that would use replication for a mde front end......

To update a user...you simply supply a whole new mde. Perhaps you miss-used
the term replication, as it has a specific meaning in
ms-access. In fact, I am rather surprised that one could use replication to
update forms, or code in a mde.....I don't think this is
possible anyway...

So I have tring to get code whereby I can update the backend.

There is several tasks you *may* need to accomplish

add a field to a existing table
add a new table
add a new table, and set relationships

The first one is quite easy...add a new field to a existing table

Dim nF As DAO.Field
Dim nT As DAO.TableDef
Dim db As DAO.Database
Dim strToDB As String

strToDB = strBackEnd ' path+name of back end

Set db = OpenDatabase(strToDB)

Set nT = db.TableDefs("tblDefaults")
nT.Fields.Append nT.CreateField("DefaultAreaCode", dbText, 3)
nT.Fields.Append nT.CreateField("DefaultCity", dbText, 25)
nT.Fields.Refresh
db.Close
Set db = Nothing

The above code simply added two fields to the table called tblDefaults

To add a new table, you actually don't have to create a linked table, since
the new mde you provide will ALREADY HAVE this new linked table. The ONLY
thing you need to do is create the new table in the back end. To save code,
I simply supply the new "empty" table in the FRONT end,and COPY it to the
back end. This saves a ton of code....saves me having to write lots to code
to create the table from scratch, and further since the new front end
already has the link set...I save further coding. I usually use some naming
standard. In my case, I just have the table name in the front end, but with
a extra capital "C" appended to the name .

Here is the code to add a new table to the back end....

strFromDB = CurrentProject.FullName
strToDB = strBackEnd

DoCmd.TransferDatabase acExport, "Microsoft Access", strToDB, acTable,
"tblDefaultsC", "tblDefaults", False

That is it...3 lines of code. What the above does is copy the a new table
called tblDefaultsC to the backend, but gives it a name of tblDefaults.
Since this is new update..the new mde that this code is running in will
already have the link to the back end for tblDefaults anyway.....


I have read some of your replies while searching on google groups and have
been playing around with Inno, as an installer.

Yes..rememeber, the reason why I use inno is that is simply better then
winzip (which I used to use). All the inno script does is unpack the mde
file to a paritclar dialry. However, it just looks better. In fact, here is
a set of screen shots as to how my software is updated

http://www.kallal.ca/ridestutorial/upgrade.html


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Well that's just great I have my orginal .mdb and synchronize with the
frontend .mde located on the server.

Everything seems to be working good and have hit no hiccups as yet. Maybe I
am wrong, and ever time it connects I am corrupting a little each time. I
will keep a look out for it.

The forms are updated with the changes, and my master .mdb is updated with
data, which is what I wanted it to do.

Thank you for the last reply with code /explanation. I find access amazing
in it's functions. Although each time a take a step farther, and have to
rethink something else and take two back. But I am getting it ~ I really
like when a light bulb goes off in my head.





"Albert D.Kallal" wrote:

As of right now. My application (beta) is running on my company's
network.
I split the database as was mentioned in your review, and have the
frontends
as .mde(s). It is a replicated copy, which is easy to make different
updates
as far as satisfiying everyones needs.

The above seems to have a issue here that is not right. You NEVER want to
use replication for updating your front ends.
Replication is for data..not forms. I can't imagine any successful setup
that would use replication for a mde front end......

To update a user...you simply supply a whole new mde. Perhaps you miss-used
the term replication, as it has a specific meaning in
ms-access. In fact, I am rather surprised that one could use replication to
update forms, or code in a mde.....I don't think this is
possible anyway...

So I have tring to get code whereby I can update the backend.

There is several tasks you *may* need to accomplish

add a field to a existing table
add a new table
add a new table, and set relationships

The first one is quite easy...add a new field to a existing table

Dim nF As DAO.Field
Dim nT As DAO.TableDef
Dim db As DAO.Database
Dim strToDB As String

strToDB = strBackEnd ' path+name of back end

Set db = OpenDatabase(strToDB)

Set nT = db.TableDefs("tblDefaults")
nT.Fields.Append nT.CreateField("DefaultAreaCode", dbText, 3)
nT.Fields.Append nT.CreateField("DefaultCity", dbText, 25)
nT.Fields.Refresh
db.Close
Set db = Nothing

The above code simply added two fields to the table called tblDefaults

To add a new table, you actually don't have to create a linked table, since
the new mde you provide will ALREADY HAVE this new linked table. The ONLY
thing you need to do is create the new table in the back end. To save code,
I simply supply the new "empty" table in the FRONT end,and COPY it to the
back end. This saves a ton of code....saves me having to write lots to code
to create the table from scratch, and further since the new front end
already has the link set...I save further coding. I usually use some naming
standard. In my case, I just have the table name in the front end, but with
a extra capital "C" appended to the name .

Here is the code to add a new table to the back end....

strFromDB = CurrentProject.FullName
strToDB = strBackEnd

DoCmd.TransferDatabase acExport, "Microsoft Access", strToDB, acTable,
"tblDefaultsC", "tblDefaults", False

That is it...3 lines of code. What the above does is copy the a new table
called tblDefaultsC to the backend, but gives it a name of tblDefaults.
Since this is new update..the new mde that this code is running in will
already have the link to the back end for tblDefaults anyway.....


I have read some of your replies while searching on google groups and have
been playing around with Inno, as an installer.

Yes..rememeber, the reason why I use inno is that is simply better then
winzip (which I used to use). All the inno script does is unpack the mde
file to a paritclar dialry. However, it just looks better. In fact, here is
a set of screen shots as to how my software is updated

http://www.kallal.ca/ridestutorial/upgrade.html


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal