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