Wrox Programmer Forums
Go Back   Wrox Programmer Forums > Visual Basic > VB 6 Visual Basic 6 > Pro VB 6
| Search | Today's Posts | Mark Forums Read
Pro VB 6 For advanced Visual Basic coders working in version 6 (not .NET). Beginning-level questions will be redirected to other forums, including Beginning VB 6.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Pro VB 6 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old August 16th, 2007, 05:55 PM
Authorized User
 
Join Date: Jul 2007
Location: Denver, CO, USA.
Posts: 24
Thanks: 0
Thanked 0 Times in 0 Posts
Default Free up access to a DBF File

Hi,

I'm currently writing a VB6 app that needs to access a Visual FoxPro DB (a file with the extension .DBF). I'm using ADO to connect to it just fine.

However, I have one problem which is I need to release the connection within my VB app, when needed. Basically, I have tried to close the ADO recordset, and then close the ADO connection object to the DBF file, but some how, that's not enough to release it. I have another app that I need to call to archive this DB, and it refuses to do so, and it keeps saying that the file is in used, but within my own VB6 app, I have already closed all connection to it.

Is there any way that I can get around this? I really need to terminate the connection to the DBF file, without having to shut down my app, because I also launch the archiving app from within my VB app so I cannot shutdown my app.

Any help is very much appreciated. Thank you very much for your time.


Khoi Nguyen
__________________
Khoi Nguyen
 
Old August 17th, 2007, 07:59 AM
Friend of Wrox
Points: 7,395, Level: 36
Points: 7,395, Level: 36 Points: 7,395, Level: 36 Points: 7,395, Level: 36
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Capital Federal, , Argentina.
Posts: 2,189
Thanks: 5
Thanked 59 Times in 57 Posts
Send a message via MSN to gbianchi
Default

hi there..

I my memory don't fail, the connection is not closed untill all the recordset that are opened are closed. The connection doesn't close that objects by itself.. So maybe you have a recordset opened somewhere (maybe a grid or a combo or something??)

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========
 
Old August 17th, 2007, 09:58 AM
Authorized User
 
Join Date: Jul 2007
Location: Denver, CO, USA.
Posts: 24
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi,

Thanks for your response. Unfortunately, I only have one recordset associated with that ADO connection. I had successfully closed that recordset before I closed the ADO connection object. Closing the ADO connection did not give me any errors, so I assumed that it worked.

Not sure where I went wrong, or if I'm missing anything here. I really appreciate any help possible.

Thank you very much.

Khoi Nguyen
 
Old August 17th, 2007, 10:51 AM
Friend of Wrox
Points: 7,395, Level: 36
Points: 7,395, Level: 36 Points: 7,395, Level: 36 Points: 7,395, Level: 36
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Capital Federal, , Argentina.
Posts: 2,189
Thanks: 5
Thanked 59 Times in 57 Posts
Send a message via MSN to gbianchi
Default

I don't have a clue them... maybe the file need some time to be released???

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========
 
Old September 28th, 2009, 11:50 AM
Authorized User
 
Join Date: Jul 2007
Location: Denver, CO, USA.
Posts: 24
Thanks: 0
Thanked 0 Times in 0 Posts
Default The issue has surfaced again.

Hi,

I have to revive this old post that did a while back. Yes, the file actually needs time to release. I have confirmed this. It would take several minutes for the file to be completely released before it can be accessed again.

Does anyone here know if a trick to speed up the release of a DBF file?

I would really appreciate your help.

Thanks.
__________________
Khoi Nguyen




Similar Threads
Thread Thread Starter Forum Replies Last Post
Excel VBA access FoxPro DBF file il_mostrino Excel VBA 0 May 16th, 2008 02:27 PM
How can I read a DBF file rtr1900 Classic ASP Databases 2 August 13th, 2007 12:36 PM
Stuck with DBF file access from Network Drive kaushalparik ASP.NET 2.0 Professional 2 April 26th, 2007 04:36 AM
SQL table to .DBF file harriet SQL Server 2005 1 May 17th, 2006 06:37 AM
How to Use foxpro's DBF file cbpanchal VB How-To 0 September 12th, 2003 03:27 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.