Solved

front end database needs FrontEndTable with local copy of BackEndLinkedTable structure

Posted on 2011-02-10
9
284 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
 
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
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
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

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

In Debugging – Part 1, you learned the basics of the debugging process. You learned how to avoid bugs, as well as how to utilize the Immediate window in the debugging process. This article takes things to the next level by showing you how you can us…
Introduction The Visual Basic for Applications (VBA) language is at the heart of every application that you write. It is your key to taking Access beyond the world of wizards into a world where anything is possible. This article introduces you to…
In Microsoft Access, when working with VBA, learn some techniques for writing readable and easily maintained code.
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…

744 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

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now