[AccessD] AXP and Error 3310

Dan Waters dwaters at usinternet.com
Mon Aug 9 16:57:39 CDT 2004


Well . . .

FSO doesn't need ADO.  Since this is a commercial app, you probably have an
installer package which could ensure that scrrun.dll is there.  FSO can also
take the full path, base name, or extensions of files and save them to
tables, as well as move/copy/delete files and folders.  

If both your apps are Access, then FSO can work with either or both.
Actually, I believe that FSO can be used/referenced by any VB/VBA
application, or VB.Net.

I would still recommend looking over what FSO can do.  If your primary
objective is moving/copying/deleting files and/or folders and recording the
information related to doing that, FSO could really be a good (and easy)
methodology.  FSO was specifically designed to make these tasks easier.

I won't bug you anymore - and I still wish you luck!

Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Monday, August 09, 2004 4:24 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] AXP and Error 3310

That isn't an option for me, Dan, but thanks for the suggestion.  I have
to make it work in the situation I described, and it has to work in a
commercial application where we have no idea what else the machine or
network may have installed/enabled.  For that reason, we try to keep
everything within Access as much as possible.  I am precluded from using
ADO because we don't want to deal with the issues of making sure the
right version of MDAC is installed, and setting a reference to the
scripting library is out of the question because handling reference
problems is less than user-friendly for runtime apps.  We are not doing
especially simple imports, and we're doing other stuff, including
updating other parts of the data file to let its parent application know
that imports have occurred.  The interaction between the applications is
a necessary complication.

Just so you all know, this app will eventually be rewritten in VB.Net,
but for now it stays in AXP.

Charlotte Foust


-----Original Message-----
From: Dan Waters [mailto:dwaters at usinternet.com] 
Sent: Monday, August 09, 2004 12:33 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] AXP and Error 3310


Charlotte,

I use File System Objects a fair amount, and I can envision using that
object model to do what you're describing here.  It's fairly simple, no
registry keys to work with, TransferText would not be needed, and you'd
only need a single application.

If you want the help file, search for Script56.chm.  The file needed on
your PC is scrrun.dll, which is installed by several different MS apps,
including Access.  You should set a reference to Microsoft Scripting to
get early binding.

Hope this helps!
Dan Waters


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
Foust
Sent: Monday, August 09, 2004 3:08 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] AXP and Error 3310

What we're doing is checking a folder at intervals for files.  There
could be a single file or multiples.  If we can copy them to another
folder, then they have been completely written.  We do NOT use the
standard method of trying to get a handle because that can cause the
file to be truncated instead of fully written.  

We create an array of the file names we were able to copy and delete
those in the monitored folder.  Any that arrive while we're processing
the current group will be picked up in the next cycle.  I'm using Shell
to pass information to a Restart.mdb which thus knows what app to
restart and the registry key to use for status flags.  The two apps
semaphore back and forth using the registry and if either of them fails
to signal, the process ends.  In the restart app, I capture the window
handle of the primary app and use a FindWindowText call to make sure
that window actually gets closed before I use shell to restart it.
Restart works fine as it is.  The problem isn't with that, it's with
TransferText in the primary application.

Charlotte Foust


-----Original Message-----
From: MartyConnelly [mailto:martyconnelly at shaw.ca] 
Sent: Monday, August 09, 2004 11:35 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] AXP and Error 3310


If you have some sort of  internal Access  indexing going wonky after 
200  or around 256 file imports, how about using Michael Kaplan's TSI 
Soon dll
to switch out of the database compact it and return.

Are you using the FindFirstChangeNotification API a la
http://vbnet.mvps.org/index.html?code/fileapi/watchedfolder.htm


Charlotte Foust wrote:

>Thanks, but I'm not using Office 2003.
>
>Charlotte Foust
>
>
>-----Original Message-----
>From: MG [mailto:mgauk at btconnect.com]
>Sent: Friday, August 06, 2004 12:16 AM
>To: 'Access Developers discussion and problem solving'
>Cc: Steve White
>Subject: RE: [AccessD] AXP and Error 3310
>
>
>There's a new update for Office 2003 called Service Pack 1.  This may
>hold some answers for you. Max Sherman
>
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
>Foust
>Sent: 05 August 2004 22:49
>To: AccessD at databaseadvisors.com
>Cc: Steve White
>Subject: [AccessD] AXP and Error 3310
>
>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.
>--
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.733 / Virus Database: 487 - Release Date: 02/08/2004
> 
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.733 / Virus Database: 487 - Release Date: 02/08/2004
> 
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada



-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list