|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Old vb6 / mdb app with "Could not delete from specified tables" erhi all, I am moving an old vb6 application from a W2K to an XP machine.
If I run the app from the XP box and with the .mdb file also on the XP box, I get the above error. If I run the app from the XP box but with the .mdb file on the W2K box, I do not get the error. Any idea where I could start with this one? Thanks for any help! The error is "Could not delete from specified tables"
Andy Show quoteHide quote "AndyK" wrote: > hi all, I am moving an old vb6 application from a W2K to an XP machine. > > If I run the app from the XP box and with the .mdb file also on the XP box, > I get the above error. > > If I run the app from the XP box but with the .mdb file on the W2K box, I do > not get the error. > > Any idea where I could start with this one? Thanks for any help! > On Wed, 8 Sep 2010 14:27:04 -0700, AndyK
<An***@discussions.microsoft.com> wrote: >hi all, I am moving an old vb6 application from a W2K to an XP machine. Sounds like a permissions problem to the MDB. You generally need> >If I run the app from the XP box and with the .mdb file also on the XP box, >I get the above error. > >If I run the app from the XP box but with the .mdb file on the W2K box, I do >not get the error. > >Any idea where I could start with this one? Thanks for any help! read/write/delete/create permissions when dealing with MDB files as Jet likes creating the LDB (locking) file. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Tony thanks for the reply, think you're onto something because although I
can't see any difference between the permissions, an .ldb is created when the ..mdb is in the "good" location, but there is no .ldb created in the one which results in the error. What could stop Access creating the .ldb? If I open the .mdb from Access directly an .ldb *is* created, so could it be something about the app opening the .mdb? Thanks Show quoteHide quote "Tony Toews" wrote: > On Wed, 8 Sep 2010 14:27:04 -0700, AndyK > <An***@discussions.microsoft.com> wrote: > > >hi all, I am moving an old vb6 application from a W2K to an XP machine. > > > >If I run the app from the XP box and with the .mdb file also on the XP box, > >I get the above error. > > > >If I run the app from the XP box but with the .mdb file on the W2K box, I do > >not get the error. > > > >Any idea where I could start with this one? Thanks for any help! > > Sounds like a permissions problem to the MDB. You generally need > read/write/delete/create permissions when dealing with MDB files as > Jet likes creating the LDB (locking) file. > > Tony > -- > Tony Toews, Microsoft Access MVP > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > For a convenient utility to keep your users FEs and other files > updated see http://www.autofeupdater.com/ > . > 1) You/your program is looking at the wrong place. or
2) The folder is write protected, or network share did not allow change Show quoteHide quote "AndyK" <An***@discussions.microsoft.com> wrote in message news:91FABFF6-EFD5-46BD-9615-E2A0F3DB4373@microsoft.com... > Tony thanks for the reply, think you're onto something because although I > can't see any difference between the permissions, an .ldb is created when > the > .mdb is in the "good" location, but there is no .ldb created in the one > which > results in the error. > > What could stop Access creating the .ldb? If I open the .mdb from Access > directly an .ldb *is* created, so could it be something about the app > opening > the .mdb? > > Thanks > > "Tony Toews" wrote: > >> On Wed, 8 Sep 2010 14:27:04 -0700, AndyK >> <An***@discussions.microsoft.com> wrote: >> >> >hi all, I am moving an old vb6 application from a W2K to an XP machine. >> > >> >If I run the app from the XP box and with the .mdb file also on the XP >> >box, >> >I get the above error. >> > >> >If I run the app from the XP box but with the .mdb file on the W2K box, >> >I do >> >not get the error. >> > >> >Any idea where I could start with this one? Thanks for any help! >> >> Sounds like a permissions problem to the MDB. You generally need >> read/write/delete/create permissions when dealing with MDB files as >> Jet likes creating the LDB (locking) file. >> >> Tony >> -- >> Tony Toews, Microsoft Access MVP >> Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm >> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ >> For a convenient utility to keep your users FEs and other files >> updated see http://www.autofeupdater.com/ >> . >> Got it: if I change the path to the .mdb in the ODBC System DSN from a mapped
drive to the full path, it works. Wonder why that makes a difference? cheers Show quoteHide quote "AndyK" wrote: > Tony thanks for the reply, think you're onto something because although I > can't see any difference between the permissions, an .ldb is created when the > .mdb is in the "good" location, but there is no .ldb created in the one which > results in the error. > > What could stop Access creating the .ldb? If I open the .mdb from Access > directly an .ldb *is* created, so could it be something about the app opening > the .mdb? > > Thanks > > "Tony Toews" wrote: > > > On Wed, 8 Sep 2010 14:27:04 -0700, AndyK > > <An***@discussions.microsoft.com> wrote: > > > > >hi all, I am moving an old vb6 application from a W2K to an XP machine. > > > > > >If I run the app from the XP box and with the .mdb file also on the XP box, > > >I get the above error. > > > > > >If I run the app from the XP box but with the .mdb file on the W2K box, I do > > >not get the error. > > > > > >Any idea where I could start with this one? Thanks for any help! > > > > Sounds like a permissions problem to the MDB. You generally need > > read/write/delete/create permissions when dealing with MDB files as > > Jet likes creating the LDB (locking) file. > > > > Tony > > -- > > Tony Toews, Microsoft Access MVP > > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > > For a convenient utility to keep your users FEs and other files > > updated see http://www.autofeupdater.com/ > > . > > On Thu, 9 Sep 2010 14:04:03 -0700, AndyK <An***@discussions.microsoft.com> wrote:
¤ Got it: if I change the path to the .mdb in the ODBC System DSN from a mapped ¤ drive to the full path, it works. Wonder why that makes a difference? ¤ If the network resource is different then I would suspect that the user does not have full permissions to the folder where the database is located or has not been authenticated. Either way I would definitely stick with using a UNC path. ODBC isn't really recommended for use with Access as the driver is not as stable and is less capable than the OLEDB providers. Paul ~~~~ Microsoft MVP (Visual Basic) On Fri, 10 Sep 2010 07:30:52 -0500, Paul Clement
<UseAdddressAtEndofMess***@swspectrum.com> wrote: >... ODBC isn't really recommended for use This is unsubstantiated opinion and a common myth.>with Access as the driver is not as stable and is less capable than the OLEDB providers. > Since Jet and ODBC are practically joined at the hip - they evolved together - Access and ODBC is about as *stable* as it can get. As for capabilities, both OLE DB and ODBC have different feature sets. For some solutions it can as easily be said OLE DB is "less capable" than ODBC. (And the same can be said for the respective data access libraries - ADO and DAO.) -ralph On Fri, 10 Sep 2010 09:57:01 -0500, ralph <nt_consultin***@yahoo.net> wrote:
¤ On Fri, 10 Sep 2010 07:30:52 -0500, Paul Clement ¤ <UseAdddressAtEndofMess***@swspectrum.com> wrote: ¤ ¤ ¤ >... ODBC isn't really recommended for use ¤ >with Access as the driver is not as stable and is less capable than the OLEDB providers. ¤ > ¤ ¤ This is unsubstantiated opinion and a common myth. Not my opinion, it's substantiated by Microsoft. ¤ Since Jet and ODBC are practically joined at the hip - they evolved ¤ together - Access and ODBC is about as *stable* as it can get. Actually the Access ODBC driver has thread safety issues (because of the version of VBA invoked). The Jet OLEDB provider has fixes and enhancements for stability which includes thread pooling for VBA. Microsoft does recommend using the OLEDB provider over the ODBC driver. Also, if I remember correctly there were some significant performance issues when upgrading to the Jet 4.0 ODBC driver. ¤ As for capabilities, both OLE DB and ODBC have different feature sets. ¤ For some solutions it can as easily be said OLE DB is "less capable" ¤ than ODBC. Not in the Access world. Some of the DDL and DML is not support by the Jet ODBC driver. Microsoft dropped the Jet ODBC driver after MDAC version 2.5. Paul ~~~~ Microsoft MVP (Visual Basic) "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message I didn't realize there was a difference.news:r0rk86hsga4hl1esnl02u4comu7vu8jtqd@4ax.com... : : Not my opinion, it's substantiated by Microsoft. On Fri, 10 Sep 2010 13:20:52 -0500, Paul Clement
<UseAdddressAtEndofMess***@swspectrum.com> wrote: Show quoteHide quote >On Fri, 10 Sep 2010 09:57:01 -0500, ralph <nt_consultin***@yahoo.net> wrote: If the OP had mentioned anything about having a multi-threaded> >¤ On Fri, 10 Sep 2010 07:30:52 -0500, Paul Clement >¤ <UseAdddressAtEndofMess***@swspectrum.com> wrote: >¤ >¤ >¤ >... ODBC isn't really recommended for use >¤ >with Access as the driver is not as stable and is less capable than the OLEDB providers. >¤ > >¤ >¤ This is unsubstantiated opinion and a common myth. > >Not my opinion, it's substantiated by Microsoft. > >¤ Since Jet and ODBC are practically joined at the hip - they evolved >¤ together - Access and ODBC is about as *stable* as it can get. > >Actually the Access ODBC driver has thread safety issues (because of the version of VBA invoked). >The Jet OLEDB provider has fixes and enhancements for stability which includes thread pooling for >VBA. Microsoft does recommend using the OLEDB provider over the ODBC driver. > application/project or the importance of "thread-safty" - then this might be relevent. He didn't and it isn't. Microsoft has recommended the use of ADO/OLE DB since the first release of ADO. Most of their motives for doing so has little to do with technology, but for reasons like - managing multiple users, easier migration to SQL Server, ..., and across a wire. >Also, if I remember correctly there were some significant performance issues when upgrading to the Your memory is incorrect, as you have it backwards. Significant>Jet 4.0 ODBC driver. > *decreases* in performance will be noticed when one *upgrades* an MSAccess project to ADO/OLE DB. >¤ As for capabilities, both OLE DB and ODBC have different feature sets. Where do you come up with this stuff?>¤ For some solutions it can as easily be said OLE DB is "less capable" >¤ than ODBC. > >Not in the Access world. Some of the DDL and DML is not support by the Jet ODBC driver. > Seriously. If you are unfamilar with Microsoft data access technologies, it would be best if you didn't respond. -ralph If you are still early, suggest you to use DAO with datasource pointing to
the path, local or network. It is much easier to set up when you change the location of MDB. Show quoteHide quote "AndyK" <An***@discussions.microsoft.com> wrote in message news:3316B15C-655A-4D1E-9C8C-02413902FE51@microsoft.com... > Got it: if I change the path to the .mdb in the ODBC System DSN from a > mapped > drive to the full path, it works. Wonder why that makes a difference? > > cheers > > "AndyK" wrote: > >> Tony thanks for the reply, think you're onto something because although I >> can't see any difference between the permissions, an .ldb is created when >> the >> .mdb is in the "good" location, but there is no .ldb created in the one >> which >> results in the error. >> >> What could stop Access creating the .ldb? If I open the .mdb from Access >> directly an .ldb *is* created, so could it be something about the app >> opening >> the .mdb? >> >> Thanks >> >> "Tony Toews" wrote: >> >> > On Wed, 8 Sep 2010 14:27:04 -0700, AndyK >> > <An***@discussions.microsoft.com> wrote: >> > >> > >hi all, I am moving an old vb6 application from a W2K to an XP >> > >machine. >> > > >> > >If I run the app from the XP box and with the .mdb file also on the XP >> > >box, >> > >I get the above error. >> > > >> > >If I run the app from the XP box but with the .mdb file on the W2K >> > >box, I do >> > >not get the error. >> > > >> > >Any idea where I could start with this one? Thanks for any help! >> > >> > Sounds like a permissions problem to the MDB. You generally need >> > read/write/delete/create permissions when dealing with MDB files as >> > Jet likes creating the LDB (locking) file. >> > >> > Tony >> > -- >> > Tony Toews, Microsoft Access MVP >> > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm >> > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ >> > For a convenient utility to keep your users FEs and other files >> > updated see http://www.autofeupdater.com/ >> > . >> > On Thu, 9 Sep 2010 14:04:03 -0700, AndyK
<An***@discussions.microsoft.com> wrote: >Got it: if I change the path to the .mdb in the ODBC System DSN from a mapped Probably because you are creating an "ODBC *System* DSN" (the emphasis>drive to the full path, it works. Wonder why that makes a difference? > is mine). Many Windows services don't work with mapped drives, since they often 'work' outside the context of the User. [Also you will note many data services often provide two properties: A Local Drive <mapped drive> A Remote Drive <UNC required> ] I'm sure there is more to it because I've seen both formats work on occasion on some O/Ss, but I've had the same issue with System DSNs. With a File DSN you can usually use either format. -ralph A map driver number can change or disappear depending on who log on.
Show quoteHide quote "AndyK" <An***@discussions.microsoft.com> wrote in message news:3316B15C-655A-4D1E-9C8C-02413902FE51@microsoft.com... > Got it: if I change the path to the .mdb in the ODBC System DSN from a > mapped > drive to the full path, it works. Wonder why that makes a difference? > > cheers > > "AndyK" wrote: > >> Tony thanks for the reply, think you're onto something because although I >> can't see any difference between the permissions, an .ldb is created when >> the >> .mdb is in the "good" location, but there is no .ldb created in the one >> which >> results in the error. >> >> What could stop Access creating the .ldb? If I open the .mdb from Access >> directly an .ldb *is* created, so could it be something about the app >> opening >> the .mdb? >> >> Thanks >> >> "Tony Toews" wrote: >> >> > On Wed, 8 Sep 2010 14:27:04 -0700, AndyK >> > <An***@discussions.microsoft.com> wrote: >> > >> > >hi all, I am moving an old vb6 application from a W2K to an XP >> > >machine. >> > > >> > >If I run the app from the XP box and with the .mdb file also on the XP >> > >box, >> > >I get the above error. >> > > >> > >If I run the app from the XP box but with the .mdb file on the W2K >> > >box, I do >> > >not get the error. >> > > >> > >Any idea where I could start with this one? Thanks for any help! >> > >> > Sounds like a permissions problem to the MDB. You generally need >> > read/write/delete/create permissions when dealing with MDB files as >> > Jet likes creating the LDB (locking) file. >> > >> > Tony >> > -- >> > Tony Toews, Microsoft Access MVP >> > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm >> > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ >> > For a convenient utility to keep your users FEs and other files >> > updated see http://www.autofeupdater.com/ >> > . >> > On Wed, 8 Sep 2010 14:27:04 -0700, AndyK <An***@discussions.microsoft.com> wrote:
¤ hi all, I am moving an old vb6 application from a W2K to an XP machine. ¤ ¤ If I run the app from the XP box and with the .mdb file also on the XP box, ¤ I get the above error. ¤ ¤ If I run the app from the XP box but with the .mdb file on the W2K box, I do ¤ not get the error. ¤ ¤ Any idea where I could start with this one? Thanks for any help! Not much info here (such as where in the code the error occurs) but it could be an issue with table relationships: http://support.microsoft.com/kb/240098 Paul ~~~~ Microsoft MVP (Visual Basic) Paul - thanks for responding
Code where error occurs is mdsrDE.cmdDeleteTxnLogs gintArchiveLogsAge Queries executed before this one with no problem are all select only, but this one is the first updating query - it runs a delete query - and it shows the error. I had seen that KB article and setting the UniqueRecords property to Yes makes no difference. As Tony suggested above I have checked the permissions on the mdb's and there is no difference that I can see - VB6.exe runs as my user name and this user has full control security rights on the mdb file in both locations Show quoteHide quote "Paul Clement" wrote: > On Wed, 8 Sep 2010 14:27:04 -0700, AndyK <An***@discussions.microsoft.com> wrote: > > ¤ hi all, I am moving an old vb6 application from a W2K to an XP machine. > ¤ > ¤ If I run the app from the XP box and with the .mdb file also on the XP box, > ¤ I get the above error. > ¤ > ¤ If I run the app from the XP box but with the .mdb file on the W2K box, I do > ¤ not get the error. > ¤ > ¤ Any idea where I could start with this one? Thanks for any help! > > Not much info here (such as where in the code the error occurs) but it could be an issue with table > relationships: > > http://support.microsoft.com/kb/240098 > > > Paul > ~~~~ > Microsoft MVP (Visual Basic) > . > 
Other interesting topics
Aero Glass Control Text Problem
Funky Font Enumeration Cant solve this. Any "quirsk" with the timer control DLL fight create desktop shortcut when app installed w/P&D installer for XP,Vista,W7 What Is the User Path for Deployment Similar to $(AppPath)? Looking for VC6 newsgroup Error 5: ERROR_ACCESS_DENIED when accessing registry in Windows 7 Calling function pointers |
|||||||||||||||||||||||
