Developer Extensions Package Wizard

[Susan R]

I packaged an Access 2003 database using the package wizard and installed the
application on a PC that does not have Access. Everything appeared to work
properly;however, when a database table was updated through the application,
it did not appear on the table when I opened it through my full version of
Access. I was under the assumption that the db could be updated through the
packaged installation. Is this correct?

 

[Albert D. Kallal]

I packaged an Access 2003 database using the package wizard and installed
the
application on a PC that does not have Access. Everything appeared to
work
properly;however, when a database table was updated through the
application,
it did not appear on the table when I opened it through my full version of
Access. I was under the assumption that the db could be updated through
the
packaged installation. Is this correct?

You have to give a bit more information when you say "the db could be
updated". You certainly can update the back end db, or use code to "modify"
table structures. If you do have code that does this, then you need to
EXTENSIVELY test this. I would suggest you grab a free copy of Virtual pc.
Virtual pc allows you to build and create a "clean" pc.

In the mean time, when you test your update code, you should create a
shortcut with the /runtime switch.....this will allow you to test your code
in a runtime environment.

Last, but not least, do be aware that you CAN NOT use automation to launch a
2nd copy of ms-access on a runtime only machine (this is due to the fact
that the runtime needs a mde (or mdb) provided as a file name, and when you
automaton, you can NOT provide this file name.

Regardless, you need to test your install on a clean machine, and then any
updates you have, then again you must test.

Test, and test again. You MUST test these install on a another clean machine
(ie: use a test mule pc and something like Norton ghost to re-image back to
a clean state, or as mentioned virtual pc).

It is not clear if you takling about updteing the front end, provindg a new
back end, or code that modifyes the table structure of hte back end (and, if
yes to the last question...then how are you doing this, and furhter as
mentoed, you can NOT use automaton in this case).

 

[Susan R]

I'm just trying to allow a user to add a record to a table through the
runtime application.

 

[Albert D. Kallal]

I'm just trying to allow a user to add a record to a table through the
runtime application.

Ok, I thought you were perhaps trying to run code that modifies the tale
structures, and as mentioned, with the runtime you *can* do this, but you
*can not* use automaton which is often used. I found this problem out the
hard way!!! So, this seem likely NOT YOUR problem.

If you just editing, and adding of data...then there should be no problem.

I really good suggestion is to simply deploy a readme.txt file with the
runtime. Then for your front end, and back end..you just copy them to the
target machine. Remember, there is no "special" connection between the
runtime, and your mde + mdb files that you distribute here.

Adding records should not be a problem at all. Have you tested this install
on a clean machine? (a clean machine is one that is similar to the type of
machine your having problems on..and one that never had the runtime
installed).

I'm just trying to allow a user to add a record to a table through the
runtime application.

The runtime does not allow users to look at, or use the tables directly. So,
by "add a record", I assume you mean via a form.

Also, is this database split? (and, if yes...do you have software for
re-linking of the tables?).

"can't add record" is not very descriptive. Is this via code, via a form, or
perhaps you looking to have a table view (which is not available).

If it just a regular form with regular navigations...then of course this
should work.....

 

[Susan R]

Thank you for your patience; I am just an accountant who has been assigned
this task.
I have a database residing in a shared file on the server. I want to allow
users who do not have a full version of access installed to use the version I
packaged through developer extensions to add records to a table using a form.

 

[Albert D. Kallal]

So, what you need to do is

a) Get the runtime installed on each of those machines.

b) install a mde front end on each machine that points to this back end.

that assumes you are going to "split" your database.

I explain splitting here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

If all of this is new to you, might consider talking to the local computers
user group, or consider talking to the original developer of that database
on your system. Most of this stuff is quite easy, but of "easy" when you
have the right knowledge.

The split concept is not really required for this, but if you plan any
multi-user access to that mdb file..then you should split the database (and
have experience working with a split system).

If the mdb file is not to be multi-user, then you can leave it on the
server, and build a short cut on your desktop etc. for the person to open
this database

(you don't mention now how you setup the shortcuts on each users desktop, or
how this mdb file is being launched an used).

Furhter, all users need FULL rights to that shared folder. I not going to
mix english here:

full rights

So, check if all users have full rights to the shared folder, since if they
don't have file create rights, and file delete rights, then the mdb file is
not able to be updated.

 

[Susan R]

I have a db in a shared folder on the server. I want to allow employees (who
do not have Access installed on their computers) to add record to tables
through forms in the db. I thought using Access 2003 Deceloper Extensions
was the easiest way to do this. I am just an accountant who ended up with
this task so most of this is beyond me. Thanks for your patience.

 

[Todos Menos [MSFT]]

I'd reccomend not using the package and deployment wizard-- and merely
copying the AccessRT.MSI from the Office 2003 Professional DIsk.

The person at Microsoft that has given us three different ways to get
the Access Runtime this decade-- should be SHOT

 

[Larry Daugherty]

Hi Susan,

You still haven't surfaced some very critical information related to
your issues.

Is your application split into FrontEnd and BackEnd MDBs? If it's
not, then you have some work to do. The first thing being to split
your application. First, save a backup copy of your application with
a modified name or even put it into a special folder. Splitting an
application sounds intimidating but it's nothing more than making a
copy of your application with a name like MyAppData.mdb and delete
everything except the tables. Rename your existing application to
MyAppGUI.mdb. In that one, delete all of the tables. Then File | Get
External Data | Link and navigate to MyAppData.mdb. Within
MyAppData.mdb select the Tables tab and choose "Select All".

Once you've done the above you can test and verify that you are
changing the data in MyAppData.mdb. Do it!


Your setup program is both your friend and your enemy. My guess is
that your setup included a monolithic database or both a FrontEnd and
a BackEnd. Leave everything in place but either you or your users
should delete both the FrontEnd and the BackEnd MDBs located on their
PCs. [The problem is that the setup program took the FrontEnd and
BackEnd that you specified when you created the setup with whatever
linkage or state was present].

If your FrontEnd MDB is not already pointed at the BackEnd MDB on the
server, use the Linked Table Manager to attach to the BackEnd on the
Server. Now, place a copy of YOUR FrontEnd MDB on each of their PCs.

That will probably fix the problem. If not, some of my assumptions
are wrong and you'll need to provide new information or emphasize what
you've provided before

HTH

 

[Tony Toews [MVP]]

"T o d o s M e n o s [ M S F T ] " < t o d o s _ m e n o s _ m s f

I'd reccomend not using the package and deployment wizard-- and merely
copying the AccessRT.MSI from the Office 2003 Professional DIsk.

The person at Microsoft that has given us three different ways to get
the Access Runtime this decade-- should be SHOT

Note that this person is really A a r o n K e m p f and that he is not an employee
of Microsoft.

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

 

[David W. Fenton]

Furhter, all users need FULL rights to that shared folder. I not
going to mix english here:

full rights

So, check if all users have full rights to the shared folder,
since if they don't have file create rights, and file delete
rights, then the mdb file is not able to be updated.

WRONG.

They don't need DELETE access. That means only that the LDB file
won't be deleted when the users exit. It does *not* prevent access
to the MDB/MDE at all.

 

[Todos Menos [MSFT]]

David;

database users NEVER need NTFS permissions
they need SQL Server permissions

stfu and stop conning people about this flaky ass engine

MDB is dead and it has been for 10 years
ADP is the most popular extension in Access 2002 and 2003



FILE, NEW -- how many options refer to MDB?
how many options refer to ADP?

do the math, kids

ADP wins every time