Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
16-12-20 10:05 AM
I am trying to access multiple MS Access DB 's one after the other using OLEDB utility in a loop.
It works for first DB file but 2nd file it throws an error- check file name is correct. Although if i run 2nd directly , it works but other fails.
So basically only running one at a time and 2nd it throws error.
Is there a data integrity issue with it.
An alternative approach to work on this?
Note: All DB's are in same folder. I am just changing the name for which file within a loop and trying to connect, query &After closing the connection, try next.
It works for first DB file but 2nd file it throws an error- check file name is correct. Although if i run 2nd directly , it works but other fails.
So basically only running one at a time and 2nd it throws error.
Is there a data integrity issue with it.
An alternative approach to work on this?
Note: All DB's are in same folder. I am just changing the name for which file within a loop and trying to connect, query &After closing the connection, try next.
Answered! Go to Answer.
1 BEST ANSWER
Helpful Answers
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
06-01-21 03:57 PM
Hi Gagandeep,
I just looked at a similar issue, and I think the problem is that once the VBO is used to connect to a specific DB instance it remains tied to that instance until the VBO is garbage collected. Unfortunately, that doesn't happen until the process completes.
Is this the main functional area of the process you're working with? I'm wondering if you can create try creating a secondary process that just touches the database. Input to the process would be the specific DB file to work with. So you would basically invoke this separate process to handle just the DB interaction. When it's done with the specific DB file, the secondary process ends. Then you invoke it again with the next DB file. Does that make sense?
This is basically the same idea as @Hossein Azimi mentioned above.
Cheers,
I just looked at a similar issue, and I think the problem is that once the VBO is used to connect to a specific DB instance it remains tied to that instance until the VBO is garbage collected. Unfortunately, that doesn't happen until the process completes.
Is this the main functional area of the process you're working with? I'm wondering if you can create try creating a secondary process that just touches the database. Input to the process would be the specific DB file to work with. So you would basically invoke this separate process to handle just the DB interaction. When it's done with the specific DB file, the secondary process ends. Then you invoke it again with the next DB file. Does that make sense?
This is basically the same idea as @Hossein Azimi mentioned above.
Cheers,
5 REPLIES 5
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
16-12-20 11:18 AM
Hi Gagandeep
I suggest creating a Business Object for each database DB file and use them sepratly.
I suggest creating a Business Object for each database DB file and use them sepratly.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
16-12-20 03:24 PM
Hi Gagandeep,
Are you attempting to attach to each database in this fashion:
Set Connection -> Open -> Get Collection/Execute -> Close -> repeat?
In other words, are you connecting a DB, doing your work, closing the connection, and then moving to the next DB? Or are you trying to open and maintain active connections to all of your DB's at the same time?
Cheers,
Are you attempting to attach to each database in this fashion:
Set Connection -> Open -> Get Collection/Execute -> Close -> repeat?
In other words, are you connecting a DB, doing your work, closing the connection, and then moving to the next DB? Or are you trying to open and maintain active connections to all of your DB's at the same time?
Cheers,
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
17-12-20 05:22 AM
Hi Eric,
Yes, we are connecting a db, getting data, closing the connecting and then moving to next db.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
05-01-21 05:19 AM
Hi @ewilson ,
As you said, I am following this order as they are different DB's files
Set Connection -> Open -> Get Collection/Execute -> Close -> repeat?
but no luck, any other alternate approach?
As you said, I am following this order as they are different DB's files
Set Connection -> Open -> Get Collection/Execute -> Close -> repeat?
but no luck, any other alternate approach?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
06-01-21 03:57 PM
Hi Gagandeep,
I just looked at a similar issue, and I think the problem is that once the VBO is used to connect to a specific DB instance it remains tied to that instance until the VBO is garbage collected. Unfortunately, that doesn't happen until the process completes.
Is this the main functional area of the process you're working with? I'm wondering if you can create try creating a secondary process that just touches the database. Input to the process would be the specific DB file to work with. So you would basically invoke this separate process to handle just the DB interaction. When it's done with the specific DB file, the secondary process ends. Then you invoke it again with the next DB file. Does that make sense?
This is basically the same idea as @Hossein Azimi mentioned above.
Cheers,
I just looked at a similar issue, and I think the problem is that once the VBO is used to connect to a specific DB instance it remains tied to that instance until the VBO is garbage collected. Unfortunately, that doesn't happen until the process completes.
Is this the main functional area of the process you're working with? I'm wondering if you can create try creating a secondary process that just touches the database. Input to the process would be the specific DB file to work with. So you would basically invoke this separate process to handle just the DB interaction. When it's done with the specific DB file, the secondary process ends. Then you invoke it again with the next DB file. Does that make sense?
This is basically the same idea as @Hossein Azimi mentioned above.
Cheers,