[AccessD] AXP and Error 3310

Gustav Brock gustav at cactus.dk
Mon Aug 9 12:15:30 CDT 2004


Hi Charlotte

I understand that.
That leaves you with the DoEvent trick from Drew and the tip on
monitoring threads from Stuart ...

Also, did you check on the printer driver? I know this is a long shot
but I've seen so many problems related to these at the latest, indeed
for drivers for the modern mega-copy-printer-scan beasts.

Would you keep us posted on progress solving this issue?

/gustav


> Unfortunately, I would have to rewrite the application to do that,
> Gustav.  If I were importing a single file, it might be OK, but we are
> unzipping a file that may contain text files exported from any group of
> the data tables in our application.  We have to loop through the
> individual tables, see if a text file for that table has been included,
> and import the data appropriately into a temporary table where any type
> or units conversion and internationalization issues can be handled
> before moving the data into the main tables.  We also have to deal with
> files that might have been created by an earlier version of our
> application, which means they may require special temporary tables to
> match the shape used in that earlier version.  You get the idea.  It
> would be a nightmare to build and maintain direct file I/O routines in
> code, complete with special handling.  I could do it, but my bosses
> would scream for a week ... And then catch their breath and start over
> again. :-{

> Charlotte Foust


> -----Original Message-----
> From: Gustav Brock [mailto:gustav at cactus.dk] 
> Sent: Friday, August 06, 2004 4:51 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] AXP and Error 3310


> Hi Charlotte

> The fail on TransferText is probably only a sympton not the error. Or
> maybe it is; it uses the "external ISAM" I guess.

> Nevertheless, you could try replacing the TransferText routine with a
> simple "Open File and read in line by line" routine. I'm sure you know
> how to this. It may even be faster than TransferText.

> /gustav


>> I'm beating my head against this and couldn't find anything in the 
>> archives or the MSKB (they seem to never have heard of error 3310), so

>> I'm looking to you guys for assistance.  We have an app that does 
>> nothing but watch a folder and import the files it finds there.  To 
>> stress test it, we set it up with a single file (which is actually a 
>> zip file containing a series of comma delimited text files, each 
>> compatible with a table in the database structure) to import 
>> repeatedly.  The import specs are there, and the thing behaves 
>> beautifully ... For a while.  Then suddenly, after it has happily 
>> imported the same file several hundred times, it loses its mind and 
>> starts throwing a 3310 error, "This property is not supported for 
>> external data sources or for databases created with a previous version

>> of Microsoft Jet" for each text file in the archive.  Mind you, this 
>> is within 60 seconds of having imported the thing before.

>> After that, NO imports are possible in the database, even from the UI 
>> until you close and restart Access.  Nothing else has changed, and the

>> database is not overly large.  It isn't an unhandled error somewhere, 
>> because the module level and global variables are still populated.  I 
>> can open the unzipped text files and see the data in them, but Access 
>> can no longer import it, not even from the UI.  I'm not getting an Out

>> of Memory error or anything else, but I can step through the code and 
>> see it break on DoCmd.TransferText.  We're running on XP but I can 
>> replicate the behavior on Win2k and it is fairly consistent across 
>> machines with different speeds and memory, although the details of
>> *when* it breaks vary slightly.

>> I have a restart functionality built, shelling out to a restart app, 
>> but I want to know what's going wrong, not just paste a bandage on it.

>> Has anyone else every encountered (and overcome) this?

>> Charlotte Foust
>> Infostat Systems, Inc.




More information about the AccessD mailing list