Solved

front end database needs FrontEndTable with local copy of BackEndLinkedTable structure

Posted on 2011-02-10
9
300 Views
Last Modified: 2012-08-13
In this application, each client computer needs a work area that holds data until it is ready to be posted to the shared database.

I used the following sql code to create it.

DoCmd.DeleteObject acTable, "FrontEndTable"
docmd.runsql "SELECT TOP 1 * INTO FrontEndTable FROM BackEndLinkedTable"

 I just ignore the single extra record that was created - it does not cause any problems.

But, what if I want the indexes to also be copied to the new table?  I tried the following, but it did not work because it simply created a duplicate link.

Any idea?

DoCmd.DeleteObject acTable, "FrontEndTable"
strNewTable = "FrontEndTable"  'or pull it from anywhere
strOldTable = "BackEndLinkedTable"  'or pull it from anywhere
DoCmd.TransferDatabase acExport, "Microsoft Access", CurrentDb.Name, acTable, strOldTable, strNewTable, True
End Sub
0
Comment
Question by:rberke
  • 4
  • 3
  • 2
9 Comments
 
LVL 20

Expert Comment

by:GrahamMandeno
ID: 34866668
Use acImport instead of acExport and specify the path to the back-end database:

DoCmd.TransferDatabase acExport, "Microsoft Access", strBackEndPath, acTable, strOldTable, strNewTable, True

--
Graham Mandeno - Access MVP
0
 
LVL 20

Accepted Solution

by:
GrahamMandeno earned 250 total points
ID: 34866679
Oops!  I copied and pasted your code and didn't change everything as intended:

DoCmd.TransferDatabase acImport, "Microsoft Access", strBackEndPath, acTable, strOldTable, strNewTable, True
0
 
LVL 14

Expert Comment

by:ldunscombe
ID: 34866881
You could also think about creating your duplicate table in the front end, With all your indexes and data types etc, and then instead of Deleting the table and re-creating it each time, simply use a delete query to delete existing records and an append query to append the new ones from your linked table.

Leigh
0
Three Reasons Why Backup is Strategic

Backup is strategic to your business because your data is strategic to your business. Without backup, your business will fail. This white paper explains why it is vital for you to design and immediately execute a backup strategy to protect 100 percent of your data.

 
LVL 20

Expert Comment

by:GrahamMandeno
ID: 34867815
Yes, I agree with Leigh about creating the table only once.  Furthermore, I would recommend that you do not create the "local" table in the front-end, because adding and deleting many records over time will bloat your front-end and make it less reliable and more prone to corruption.

Instead, create a local back-end with the duplicate tables as required and link them to the front-end.  You can then move records between the local and shared tables just as easily as if the local tables were resident in the front-end.

To delete all (or some) records from a table, you don't need to create and save a delete query.  Simply execute a SQL delete statement from VBA:

CurrentDb.Execute "Delete * from [your local table]"

--
Graham
0
 
LVL 14

Expert Comment

by:ldunscombe
ID: 34867973
As Graham suggest's creating the table in the back end is more desireable, however if for some reason the table needs to be in the front end ie, Network issues, Take Offsite, Performance issues etc I would recommend setting your DB to "Compact On Close" to ease the bloating issue that Graham mentioned.

Leigh
0
 
LVL 20

Expert Comment

by:GrahamMandeno
ID: 34868090
Sorry - perhaps I didn't explain myself clearly...

I didn't mean to suggest you create the "work area" tables in THE back-end.  What I meant was that you should have two back-ends - one on the shared location on the server, and one on the local hard drive.  Link the tables from both back-ends to your front-end.

Create the "work area" tables in the local back-end, along with all the required indices and relationships, and use SQL statements (Delete, Update, and Insert into) to move records between the two back-ends as required.

--
Graham
0
 
LVL 14

Expert Comment

by:ldunscombe
ID: 34868105
OIC,

Sorry you did explain correctly,  I just miss interpereted.

Still, Regular compacts on both back ends would still be advisable.

Leigh
0
 
LVL 5

Author Comment

by:rberke
ID: 34874500
Thanks, that worked fine:

On Error Resume Next
DoCmd.DeleteObject acTable, "FrontEndTable"
On Error GoTo 0
strNewTable = "FrontEndTable"  'or pull it from anywhere
strOldTable = "BackEndLinkedTable"  'or pull it from anywhere
strBackEndPath = "S:\my program files\Back End Billing.mdb"
DoCmd.TransferDatabase acImport, "Microsoft Access", strBackEndPath, acTable, strOldTable, strNewTable, True

And your suggestion about putting it on the backend etc don't really help in this situation.  
From past experience, when a front end table is entirely temporary, my approach of creating a local copy is really the best - no conflict with other users, no access to the network etc.

And, my front ends never get bloated because the user logon procedure deletes the local MDB and refreshes it from the server.

Just a few more details if anybody is interested.

#1 user pushes an access button and my program does the following
   #1a  goes to the government website and downloads a webpage with data
   #1b  process that webpage and extracts information to a temporary FrontEndTable.
   #1d  performs integrity checks to insure that the FrontEndTable in a "clean" status.
   #1e  if and only if the temporary table is clean, the data user is given an option to upload the file to the BackEndLinkedTable
 
The programs are being changed frequently, and new columns are being added to BackEndLinkedTable almost every week which is why I like to clone the structure everytime the program is run.

In this particular situation, there are no advantages to having the clone be in the back end.
 

 
0
 
LVL 5

Author Closing Comment

by:rberke
ID: 34874554
Upon rereading, on noticed that Graham was suggesting a second back-end that would be on the local drive.  Which is almost identical to my approach.  But, it would not work well in my situation for some funky technical reasons.

rberke
0

Featured Post

Migrating Your Company's PCs

To keep pace with competitors, businesses must keep employees productive, and that means providing them with the latest technology. This document provides the tips and tricks you need to help you migrate an outdated PC fleet to new desktops, laptops, and tablets.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When you are entering numbers in a speadsheet, and don't remember what 6×7 is, you just type “=6*7" instead. It works in every cell! This is not so in Access. To enter the elusive 42 in a text box, you have to find a calculator, and then copy the re…
Phishing attempts can come in all forms, shapes and sizes. No matter how familiar you think you are with them, always remember to take extra precaution when opening an email with attachments or links.
Familiarize people with the process of utilizing SQL Server views from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Access…
With Microsoft Access, learn how to start a database in different ways and produce different start-up actions allowing you to use a single database to perform multiple tasks. Specify a start-up form through options: Specify an Autoexec macro: Us…

785 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question