Deploying Access 2002 using linked tables (1 Viewer)

[DemonDNF]

Hi,

I have separated the data from forms/reports/etc to facilitate future updates:

- Program MDE
- Data MDB

(if I understood forum threads properly, this is the recommended technique)

What is the normal way to deploy these? Do I just provide the user with instructions to link to the tables?

Open Program MDE
Click FILE
Select Get External data
Select Link Table
Enter data MDB name and location
Select All Tables
Click OK

I haven't seen a way to automate this process. I suppose the nice thing about it is that it gives the user the possibility of storing his data on a separate drive (I store programs on partition C, data on partition D - makes things easier when I reformat).

Robert

 

[pr2-eugin]

DemonDNF, the main idea of splitting the DB is to avoid users gaining access to tables directly. Also, Splitting DB is also the best strategy to help attain multi user access to Databases. If you are the only person using the DB it is not 100% required that you need to split it.

Although there are several threads and working samples for linking tables dynamically. Before looking for that, let us know why do you wish to give the user Access to Dynamically link tables.

 

[DemonDNF]

Like I said in post #1, it is mainly to make things easier if I have to send a user updated VBa code, forms, reports, etc.

In theory, the intent is to market this MDE. It is intended and designed for single-user environment.

I guess I answer my own question because if I send the user an updated MDE, they will have to link to the data MDB anyways.


I didn't know the proper term was "Dynamically linked tables". I used "deploy linked tables", which didn't seem to return useful threads by reading their titles.

I will read up on Dynamically linked tables.

Robert


EDIT: This thread is interesting:
http://www.access-programmers.co.uk/forums/showthread.php?t=178633

 

[pr2-eugin]

Like I said in post #1, it is mainly to make things easier if I have to send a user updated VBa code, forms, reports, etc.

In that case (update VBA code, forms, reports) has nothing to do with linking tables. As everytime a change in the front end file is made the front end needs to be replaced. There would be no need for updating the linked tables.

What you need is, Microsoft Access Front-End Auto-Update Enabling Tool

 

[DemonDNF]

LOL

That is excellent. I was going to do a skeleton version; a form to manage the path to the data MDB and storing it in a hidden table.

That puppy does it all, neat stuff!

Robert

 

[pr2-eugin]

Ha Ha ! Good Luck !

 

[DemonDNF]

DemonDNF, the main idea of splitting the DB is to avoid users gaining access to tables directly...

I haven't seen anything from stopping a user from opening the data MDB and playing with the tables directly.

I do understand that using an MDE for the "program components" protects my work to a limitted degree.

Is there a way to lock the data MDB from user editting?

Do you know of a utility to create/manage deployment passwords (like cd keys)?

Any suggestion for a low cost source of access 2002 runtime?

Those are the last main issues I have to address before I deploy a beta version for testing (google should provide me with a decent NDA).

I have an installer, can't remember the name.

Robert

 

[gemma-the-husky]

if you only have/want a single user, then there are some fors and againsts

It is far easier to distribute a single user system. A user can put the dbs anywhere and use it.

If you separate the fe and be, then users need

a) to put the fe and be in separate locations (although they could be the same)
b) to find a way to link the two together

As a developer you also have a bigger security issue with a split database - if you want to restrict the number of active users.

However, with a single user database, you have a different problem of deploying a new front end - since you really need to get the data out of the old system, and into the new one.

It's something you need to think about as developer, and decide which you want.

Adding security in a split database is not so easy, though.

 

[DemonDNF]

I am more interested in an installer-level password. Access 2002 information is all over the web. Anyone that reallly wants to can get into the MDB. It won't do them much good if forms, reports, VBA etc are in an MDE.

This is targetting hobbyists with a specific need; priced similar to android apps. I'm not worried about multi-users; I'm using default record locks.

I would just like to "limit" pirating.

Robert

 

[Lightwave]

Demon potentially you just need to distribute the front end.....!!!

I just discovered that in Access 2003 you can use UNC paths to link tables.

I'm guessing but you probably be able to do this in other versions of MS Access as well.

So just use the UNC path to your back end and then distribute and it should just work. Of course you would have to maybe get that path from each customer and set up before e-mailing new MDE out to each of them but still might have potential.

I only discovered this TODAY!. Previously the difficulty I've always had was with getting pathing to work with the linked table manager. In the past I've any linking has always been relative to the client machine and not independent and I've had to go in and map a network drives for each client to the same location and ensure that I always map the same letter. But I think this was never needed.

In Access 2003

Type out the full UNC path to the backend and copy and paste it to the clipboard.

Now simply when the linked table manager appears rather than using the combo box within the File Dialog Manager to navigate to the backend simply paste the full UNC path to the backend into the File name box at the bottom.

After ok the link to the table will be full UNC and not relative to the client machine. Repeat for each table.

Works a treat for me...

Turns out that UNC will be recorded its just that the combo box at the top of that file dialog box doesn't accept them... oh boy I wish I'd know about this 5 years ago.

Paul / Dave did you guys know this tip?

 

[DemonDNF]

Lightwave, check out the tool in post #4. It's open source too, so you can open it up and take pieces that suit your needs.

I just looked at the main screen, haven't had time to look at what goes on in background. I glanced through the help file, didn't understand everything 100% but I should be able to figure it out eventually.

Robert