Old vb6 / mdb app with "Could not delete from specified tables" er

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!

0
Utf
9/8/2010 9:27:04 PM
vb.general.discussion 1016 articles. 0 followers. Follow

22 Replies
1195 Views

Similar Articles

[PageSpeed] 24

The error is "Could not delete from specified tables" 

Andy

"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!
> 
0
Utf
9/8/2010 9:30:06 PM
On Wed, 8 Sep 2010 14:27:04 -0700, AndyK
<AndyK@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/
0
Tony
9/8/2010 10:03:05 PM
On Wed, 8 Sep 2010 14:27:04 -0700, AndyK <AndyK@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)
0
Paul
9/9/2010 12:56:51 PM
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



"Paul Clement" wrote:

> On Wed, 8 Sep 2010 14:27:04 -0700, AndyK <AndyK@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)
> .
> 
0
Utf
9/9/2010 7:49:03 PM
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
> <AndyK@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/
> .
> 
0
Utf
9/9/2010 8:14:03 PM
1) You/your program is looking at the wrong place. or
2) The folder is write protected, or network share did not allow change


"AndyK" <AndyK@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
>> <AndyK@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/
>> .
>> 


0
Phil
9/9/2010 8:28:17 PM
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
> > <AndyK@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/
> > .
> > 
0
Utf
9/9/2010 9:04:03 PM
On Thu, 9 Sep 2010 14:04:03 -0700, AndyK <AndyK@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)
0
Paul
9/10/2010 12:30:52 PM
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.


"AndyK" <AndyK@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
>> > <AndyK@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/
>> > .
>> > 


0
Phil
9/10/2010 1:53:44 PM
On Fri, 10 Sep 2010 07:30:52 -0500, Paul Clement
<UseAdddressAtEndofMessage@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.

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
0
ralph
9/10/2010 2:57:01 PM
On Thu, 9 Sep 2010 14:04:03 -0700, AndyK
<AndyK@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?
>

Probably because you are creating an "ODBC *System* DSN" (the emphasis
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
0
ralph
9/10/2010 3:25:00 PM
A map driver number can change or disappear depending on who log on.


"AndyK" <AndyK@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
>> > <AndyK@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/
>> > .
>> > 


0
Phil
9/10/2010 3:30:10 PM
On Fri, 10 Sep 2010 09:57:01 -0500, ralph <nt_consulting64@yahoo.net> wrote:

� On Fri, 10 Sep 2010 07:30:52 -0500, Paul Clement
� <UseAdddressAtEndofMessage@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)
0
Paul
9/10/2010 6:20:52 PM
"Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in message 
news:r0rk86hsga4hl1esnl02u4comu7vu8jtqd@4ax.com...
:
: Not my opinion, it's substantiated by Microsoft.

I didn't realize there was a difference. 

0
Kevin
9/10/2010 6:31:20 PM
On Fri, 10 Sep 2010 13:20:52 -0500, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:

>On Fri, 10 Sep 2010 09:57:01 -0500, ralph <nt_consulting64@yahoo.net> wrote:
>
>� On Fri, 10 Sep 2010 07:30:52 -0500, Paul Clement
>� <UseAdddressAtEndofMessage@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.
>

If the OP had mentioned anything about having a multi-threaded
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
>Jet 4.0 ODBC driver.
>

Your memory is incorrect, as you have it backwards. Significant
*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.
>� 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.
> 

Where do you come up with this stuff?

Seriously. If you are unfamilar with Microsoft data access
technologies, it would be best if you didn't respond.

-ralph
0
ralph
9/10/2010 9:44:12 PM
On Fri, 10 Sep 2010 11:30:10 -0400, "Phil Hunt" <aaa@aaa.com> wrote:
  
>A map driver number can change or disappear depending on who log on.

So use the UNC, ie \\servername\sharename\foldername\mdbname.mdb.

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/
0
Tony
9/12/2010 9:54:50 PM
On Thu, 9 Sep 2010 14:04:03 -0700, AndyK
<AndyK@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.  

Orfinarily I avoid DSNs and just go with a connection string.  Then
there's no need to have anyone configure DSNs.

But if you are dealing with an MDB why even use a DSN at all?

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/
0
Tony
9/12/2010 9:55:48 PM
On Sun, 12 Sep 2010 15:55:48 -0600, Tony Toews
<ttoews@telusplanet.net> wrote:

>On Thu, 9 Sep 2010 14:04:03 -0700, AndyK
><AndyK@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.  
>
>Orfinarily I avoid DSNs and just go with a connection string.  Then
>there's no need to have anyone configure DSNs.
>
>But if you are dealing with an MDB why even use a DSN at all?
>

The advantage to a DSN (and for its OLE DB equivalent - the UDL or
Data Link File) is that it is dynamic and allows a program to point to
different sources and configurations through a single identifier,
administered through a dialog, without hardcoding this information
within a program.

You can achieve the same ability through other means, so it becames a
matter of context and comfort level whether to use them or not.

If you visit the web you'll discover many discussions on DSN vs.
DSN-less connections - Some with valid arguments, some specious, and
some quite violent. <bg>

-ralph
0
ralph
9/12/2010 10:57:39 PM
On Sun, 12 Sep 2010 17:57:39 -0500, ralph <nt_consulting64@yahoo.net>
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.  
>>
>>Orfinarily I avoid DSNs and just go with a connection string.  Then
>>there's no need to have anyone configure DSNs.
>>
>>But if you are dealing with an MDB why even use a DSN at all?
>>
>
>The advantage to a DSN (and for its OLE DB equivalent - the UDL or
>Data Link File) is that it is dynamic and allows a program to point to
>different sources and configurations through a single identifier,
>administered through a dialog, without hardcoding this information
>within a program.
>
>You can achieve the same ability through other means, so it becames a
>matter of context and comfort level whether to use them or not.
>
>If you visit the web you'll discover many discussions on DSN vs.
>DSN-less connections - Some with valid arguments, some specious, and
>some quite violent. <bg>

But DSNs need to be setup, maintained, etc.  A connection string is
saved within your program settings.  To me it's a no-brainer.

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/
0
Tony
9/13/2010 12:40:05 AM
On Sun, 12 Sep 2010 18:40:05 -0600, Tony Toews
<ttoews@telusplanet.net> wrote:

>On Sun, 12 Sep 2010 17:57:39 -0500, ralph <nt_consulting64@yahoo.net>
>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.  
>>>
>>>Orfinarily I avoid DSNs and just go with a connection string.  Then
>>>there's no need to have anyone configure DSNs.
>>>
>>>But if you are dealing with an MDB why even use a DSN at all?
>>>
>>
>>The advantage to a DSN (and for its OLE DB equivalent - the UDL or
>>Data Link File) is that it is dynamic and allows a program to point to
>>different sources and configurations through a single identifier,
>>administered through a dialog, without hardcoding this information
>>within a program.
>>
>>You can achieve the same ability through other means, so it becames a
>>matter of context and comfort level whether to use them or not.
>>
>>If you visit the web you'll discover many discussions on DSN vs.
>>DSN-less connections - Some with valid arguments, some specious, and
>>some quite violent. <bg>
>
>But DSNs need to be setup, maintained, etc.  A connection string is
>saved within your program settings.  To me it's a no-brainer.
>

Only because you are thinking of solutions for YOUR problem and YOUR
administrative domain. <bg>

Take a scenario where you have an AS/400 data server and it contains a
'test/developer' database, and the production database. Inside your
program you identify a DSN datasource called "CurrentDataSource".

Inside the program you define your "Open" with "CurrentDataSource" and
forget it.

Developers can open the ODBC Administrator and create a DSN that
points to the test database, toggle tracing, pools, etc. Even change
to alternative datasources. They can also hard-code the user/psswrd in
the DSN to save a bit of development time. Test out different drivers.
Back in the day it was also common to test against a local file-base
database, or a separate 'test' AS/400 datasource.

[It is a rare DBA that allows developers unlimited access to a
production service. <g>]

The program, *without* change, is distributed to client boxes. The
administrator sets up a system DSN pointing to the production
database. 

What if you have some clients that need only access to an "Eastern
datasource", others need access to the "Pacific datasource".
Reconfigure the DSN on the client box. No touching of the program is
necessary.

Perhaps later you want to test your program on a client's machine. 
You go in modify the DSN for "MyData" that points to the development
server and have at it. Again - No touching of the program is
necessary.

Now, how would you mimic such dynamic behavior with a DSN-less
connection string?

Well you would probably write to the Registry, or use an INI file. But
consider the Registry is where System DSNs are already stored. And
what's the real difference between an INI file and a DSN File?

Also you could easily write your own configuration dialog, and make it
part of your program, but why? The ODBC Administrator and Data Link
dialogs are already written, tested, and available.

I'm really not defending DSNs. I'm not even saying they are the best
solution for the above scenario. I'm only saying it is A solution, and
it is one still used in many shops.

-ralph
PS: I'd probably supply a configuration database. But ... <g>
0
ralph
9/13/2010 3:17:26 AM
On Sun, 12 Sep 2010 22:17:26 -0500, ralph <nt_consulting64@yahoo.net>
wrote:
  
>Only because you are thinking of solutions for YOUR problem and YOUR
>administrative domain. <bg>

Well, sure but ....

>[It is a rare DBA that allows developers unlimited access to a
>production service. <g>]

For my clients I'm the DBA.

>I'm really not defending DSNs. I'm not even saying they are the best
>solution for the above scenario. I'm only saying it is A solution, and
>it is one still used in many shops.

And you do argue your point persuasively.  BTW I used to work on IBM
S/34s, S/36s, S/38s and AS/400s.

>PS: I'd probably supply a configuration database. But ... <g>

<smile>  Likewise.  My clients have always allowed me access to
production systems.  BUT I have code in there that if the developers
are linked to the production system the main menu turns a nice red.
Very noticable.  <smile>   

I'm not admitting to screwing up but I have.

Of course in Access it's a little easier to determine dev systems vs
user systems as we only ever give users MDEs.    The developers are
using MDBs.   Note to those unfamiliar with Access MDEs have the
viewable code stripped out of them and are "compiled".

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/
0
Tony
9/13/2010 3:37:51 AM
On Sun, 12 Sep 2010 21:37:51 -0600, Tony Toews
<ttoews@telusplanet.net> wrote:

>On Sun, 12 Sep 2010 22:17:26 -0500, ralph <nt_consulting64@yahoo.net>
>wrote:
>  
>>Only because you are thinking of solutions for YOUR problem and YOUR
>>administrative domain. <bg>
>
>Well, sure but ....
>
>>[It is a rare DBA that allows developers unlimited access to a
>>production service. <g>]
>
>For my clients I'm the DBA.
>
>>I'm really not defending DSNs. I'm not even saying they are the best
>>solution for the above scenario. I'm only saying it is A solution, and
>>it is one still used in many shops.
>
>And you do argue your point persuasively.  BTW I used to work on IBM
>S/34s, S/36s, S/38s and AS/400s.
>

I picked the AS/400 in my example to avoid the usual ... "Oh yeah?
Well you shouldn't be using ODBC in the first place." Not from you but
from others that haunt this place that always seem compelled to trash
ODBC (and DAO) and anything associated with them whenever they are
mentioned. <bg>

The native client for AS/400 is ODBC. DAO works well with AS/400 in
client applications though other object libraries are now available.

-ralph
0
ralph
9/13/2010 5:58:20 AM
Reply:

Similar Artilces:

Could not delete from specified tables
I created the following query but I get the "Could Not Delete From Specified Tables" error. Although I have access to the table and can delete from that table manually. my query is as follows: DELETE DISTINCTROW tblSatAdv.* FROM tblSatAdv INNER JOIN ( SELECT Max(tblSatAdv.SnapshotInvDte) AS MaxOfSnapshotInvDte FROM tblSatAdv ) AS MAXDTE ON tblSatAdv.SnapshotInvDte = MAXDTE.MaxOfSnapshotInvDte; It is not possible to delete using a aggregate sub Query as a joined "table" Pieter "ISUTri" <GraberJ@gmail.com> wrote in message news:ce6eaad7-6db5-4f03-...

Old vb6 / mdb app with "Could not delete from specified tables" er
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! The error is "Could not delete from specified tables" Andy "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...

Could not delete from specified tables. (Error 3086)
I have a delete query that works as select query, but will errors when changed to a delete query. As part of the query I have the table I am deleting the records from as well as a query limits to records to be deleted. The main table contains invoice attributes with a multi-field primary key (invoice number & revenue category). The query may list multiple invoice numbers, but always unique. So the relationship is always many to one. I ran into a similar situation with update queries, but once I converted the limiting query into a Make Table Query and used the results of the new...