[AccessD] AXP and Error 3310

Hi Charlotte

OK. Then I have another suggestion which is working successfully for
me. 
If you are not creating temp queries and the like, write-protect the
application file. At the same time that eliminates any need for
compacting etc.
If you are importing the text files into the app itself, move those
tables to an external, temp base. You don't even need to compact that
as you can create it from scratch when needed (at launch of the app
and/or after a finished import, prior to the next).

/gustav


> I was already using DoEvents.  We have simple deskjets in the office,
> and I see the same behavior on machines with no printer at all.
> Remember, we aren't printing anything and there aren't any reports
> involved, we're just importing files and logging information to tables
> or to text files.

> I haven't had a chance to review Stuart's suggestions yet.

> Charlotte Foust


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


> 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.