Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 520
  • Last Modified:

transferspreadsheet fails within transaction

hey guys,

when i use DoCmd.TransferSpreadsheet within a transaction i get an error

transactions
DBEngine.Workspaces(0).BeginTrans
Call DoCmd.TransferSpreadsheet(acImport, acSpreadsheetTypeExcel9, "LOCALImport_Activity_tbl", strActivitiesImportFile, True)
DBEngine.Workspaces(0).CommitTrans

Open in new window


Question --> 1) i believe it is impossible to use DoCmd.TransferSpreadsheet within a transaction. is this true?
2) could yall explain why this is impossible? i believe it's because the tables are locked against external transactions so that it Access can roll back transactions within Access (sorry a simplified explanation!)
0
developingprogrammer
Asked:
developingprogrammer
  • 4
  • 3
  • 2
2 Solutions
 
mbizupCommented:
Are you saying that you are recieving that error with just those three lines of code?

If so, then 'something else' is tying up your table.

These three lines work without issue for me:

DBEngine.Workspaces(0).BeginTrans
Call DoCmd.TransferSpreadsheet(acImport, , "tblTest", "C:\Users\myname\Desktop\testfile.xls", True)
DBEngine.Workspaces(0).CommitTrans

Open in new window

0
 
developingprogrammerAuthor Commented:
hi mbizup!

thanks for that! i didn't think other things were affecting the code but as per your suggestion i retried it and i realised that the cause of the problem is this specifically

    DBEngine.Workspaces(0).BeginTrans
            Call CurrentDb.Execute("DELETE * FROM LOCALImport_Activity_tbl;", dbFailOnError)
            
            Call DoCmd.TransferSpreadsheet(acImport, acSpreadsheetTypeExcel9, "LOCALImport_Activity_tbl", strActivitiesImportFile, True)
    DBEngine.Workspaces(0).CommitTrans

Open in new window


hrmm... i'm just trying to think why would it cause a problem? i really can't understand it. works perfectly if i don't put transactions
0
 
PatHartmanCommented:
It is possible that the Delete is causing the problem because it creates its own transaction and  that would make a transaction within a transaction.  Remember that when you run an action query from the GUI, you get a message at the end that allows you to undo the changes.  That tells you that the action happens within a transaction.  I'm not sure how using the Execute method impacts the procedure since you don't get the roll back option but it looks like the transaction is still happening.

If you really need to keep the old data if the new data doesn't get imported, you may need to back it up yourself and put it back if necessary.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
mbizupCommented:
OK - here's what's happening (my understanding):

Both of those statements affect the same table in different ways.  The delete statement removes records; the transferspreadsheet statements adds records.

IF you were deleting records from a very large table, it might take a while.  You wouldn't want your records from the spreadsheet to be inserted *before* the deletion is complete, right?  Because if that happened some or all of your inserted records would get deleted --> unpredictable results.

So my understanding of transactions is that they protect against that sort of situation.

1.  You begin a transaction
2.   You initiate a delete query on LOCALImport_Activity_tbl
3.   Access LOCKS that table specifically for your delete query, but doesn't commit the deletion -- which you can roll back.  No other data changes (action queries, transfer spreadheet, etc) can be run against the LOCALImport_Activity_tbl at this time.
4.   You commit the transaction (CommitTrans), and the lock on the table is released

The problem with your code is that you are trying to run TransferSpreadheet, which is effectively an INSERT query at stage 3, when the table is locked specifically for the DELETE query, before that transaction has been committed (so it fails -- which is a good thing :-)  )

The correct placement for the TransferSpreadsheet would be either on it's own or in a *separate* transaction  AFTER the commitTrans statement for the DELETE query.
0
 
developingprogrammerAuthor Commented:
whao mbizup and Pat, your explanation is really great and i really, really enjoy learning from you all!! it's so enlightening = )

i think what Pat says and what you're saying is quite similar with some slight differences (kindly feel free to correct me if i'm wrong)

Pat is saying the problem is a transaction in a transaction.
mbizup is saying that there is a modification to a transaction-locked table

hrmm i think mbizup to prove that your postulate is correct, i will have to try and run an action query against the table to see if it fails or not. at the moment i'm kinda time strapped and i guess understanding the effect for this case doesn't really change the outcome that much however i'm definitely bearing this in mind - the locking of tables for transactions.

Pat i think what you're saying makes sense and the point about the GUI i think is a really really good one. i didn't think of interpreting the GUI's "undo" as putting the action query in a transcation - but now i do = )

ok guys, your 2 postulates are definitely enlightening enough for me as a business application programmer - if i were in academia / research then i'll go deeper - but i'm learning to embrace my constraints and focus on getting the app up and running! thanks for spending the time to share mbizup and Pat! = ))
0
 
mbizupCommented:
<guys>

gals  

(saying that with a light spirit intended -- we're a bit of a minority on technical forums, and it is very nice to see Pat as a newcomer here.)
0
 
developingprogrammerAuthor Commented:
haha yes i've seen other experts address you as Miriam but without consent i still address you as mbizup for respect of the anonymity the nick provides! = PP

what i didn't know that Pat is a gal as well! i thought Patrick = ) great to be taught by the gals of EE!! = ))
0
 
PatHartmanCommented:
Thanks Miriam.  Have we met somewhere else?
0
 
mbizupCommented:
Pat - definitely through the MVP community, possibly elsewhere.
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

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