• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 343
  • Last Modified:

front end database needs FrontEndTable with local copy of BackEndLinkedTable structure

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
rberke
Asked:
rberke
  • 4
  • 3
  • 2
1 Solution
 
GrahamMandenoCommented:
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
 
GrahamMandenoCommented:
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
 
ldunscombeCommented:
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
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
GrahamMandenoCommented:
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
 
ldunscombeCommented:
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
 
GrahamMandenoCommented:
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
 
ldunscombeCommented:
OIC,

Sorry you did explain correctly,  I just miss interpereted.

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

Leigh
0
 
rberkeConsultantAuthor Commented:
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
 
rberkeConsultantAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now