TransferSpreadsheet Errors

  • Follow


In my code, I'm using TransferSpreadsheet and all is working fine.  However, 
should the spreadsheet contain an error, a table is created within my Acc2007 
database containing any errors that ocurred.  Although this is nice to have, 
I'm worried that I'll end up with countless error tables after awhile.  

Is there a switch I can use or a parameter I can set to prevent this table 
from being created? (The data is useless.)

I guess I can also look for an error-table after the TransferSpreadsheet 
executes and delete it (although the error-table name changes based upon the 
worksheet name which migh make it difficult to do so.)
0
Reply Utf 1/15/2010 1:08:02 PM

On Fri, 15 Jan 2010 05:08:02 -0800, kenrav
<kenrav@discussions.microsoft.com> wrote:

That table is not useless. You could use it to understand where the
errors are, and perhaps even fix the Excel records before import.
There is no way to turn this off. Indeed you can delete after the
fact. The beginning of that table name is constant, so you can find
them that way:
dim td as dao.tabledef
for each td in currentdb.tabledefs
  if left$(td.name, len("first-part-of-name") = "first-part-of-name"
then currentdb.tabledefs.delete td.name
next
(Of course you replace "first-part-of-name" with the constant part of
the error table name)

-Tom.
Microsoft Access MVP


>In my code, I'm using TransferSpreadsheet and all is working fine.  However, 
>should the spreadsheet contain an error, a table is created within my Acc2007 
>database containing any errors that ocurred.  Although this is nice to have, 
>I'm worried that I'll end up with countless error tables after awhile.  
>
>Is there a switch I can use or a parameter I can set to prevent this table 
>from being created? (The data is useless.)
>
>I guess I can also look for an error-table after the TransferSpreadsheet 
>executes and delete it (although the error-table name changes based upon the 
>worksheet name which migh make it difficult to do so.)
0
Reply Tom 1/15/2010 1:46:51 PM


1 Replies
384 Views

(page loaded in 0.117 seconds)

Similiar Articles:
















7/16/2012 4:07:23 PM


Reply: