Hi,
I have created a VB program to perform DTS tasks for data transfer from
ACCESS database to SQL Server. The DTS are created by saving the actual DTS
packages as VB file and used those bas files in VP app to run the DTS
programmatically.
The process works fine most of the time.
But occassionally the DTS process is getting locked. The two connections
from the DTS package to SQL server database gains DB lock on the database
and so the process does not go further .
Can any body know why this is happenning?
what could be the solution for this problem?
please help.
thanks
SamTracing Deadlocks
http://www.sqlservercentral.com/col...ngdeadlocks.asp
AMB
"Sam" wrote:
> Hi,
> I have created a VB program to perform DTS tasks for data transfer from
> ACCESS database to SQL Server. The DTS are created by saving the actual DT
S
> packages as VB file and used those bas files in VP app to run the DTS
> programmatically.
> The process works fine most of the time.
> But occassionally the DTS process is getting locked. The two connections
> from the DTS package to SQL server database gains DB lock on the database
> and so the process does not go further .
> Can any body know why this is happenning?
> what could be the solution for this problem?
> please help.
> thanks
> Sam
>
>
Showing posts with label program. Show all posts
Showing posts with label program. Show all posts
Tuesday, March 27, 2012
Sunday, March 25, 2012
Deadlock transaction
I have a customer using our program with SQL server and is
occasionally getting a "Transaction (process ID xxxxx) was deadlocked
on lock resources with another process and has been chosen as the
deadlock victim." From what they are telling me, there shouldn't be
any deadlock happening as they say this happens when they invoicing in
a different program that is accessing a different database. Also the
error is happening on an SQL Select from a view and this select is
then showing data in an HTML table for the user. I don't think this
view should need to lock anything, I just want to read the data. Is
there anything I can do to fix this?On Jun 22, 8:17 am, Altman <balt...@.easy-automation.comwrote:
Read "Analyzing Deadlocks with SQL Server Profiler" in BOL.
This may on the other hand lead to that the query returns incorrect
results, which may even more seroius. There are situations where NOLOCK
is called for, but you need to understand the implications. If you
don't - don't try it.
>
This may on the other hand lead to that the query returns incorrect
results, which may even more seroius. There are situations where NOLOCK
is called for, but you need to understand the implications. If you
don't - don't try it.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
I Think that the nolock will work for me. I understand the
implications and I think that my program will be able to handle it.
What I would've liked better was something like read committed but
didn't lock records.|||On Jun 26, 10:30 am, Altman <balt...@.easy-automation.comwrote:
>
>
>
>
I Think that the nolock will work for me. I understand the
implications and I think that my program will be able to handle it.
What I would've liked better was something like read committed but
didn't lock records.
If you are on 2005, consider snapshot isolation.
occasionally getting a "Transaction (process ID xxxxx) was deadlocked
on lock resources with another process and has been chosen as the
deadlock victim." From what they are telling me, there shouldn't be
any deadlock happening as they say this happens when they invoicing in
a different program that is accessing a different database. Also the
error is happening on an SQL Select from a view and this select is
then showing data in an HTML table for the user. I don't think this
view should need to lock anything, I just want to read the data. Is
there anything I can do to fix this?On Jun 22, 8:17 am, Altman <balt...@.easy-automation.comwrote:
Quote:
Originally Posted by
I have a customer using our program with SQL server and is
occasionally getting a "Transaction (process ID xxxxx) was deadlocked
on lock resources with another process and has been chosen as the
deadlock victim." From what they are telling me, there shouldn't be
any deadlock happening as they say this happens when they invoicing in
a different program that is accessing a different database. Also the
error is happening on an SQL Select from a view and this select is
then showing data in an HTML table for the user. I don't think this
view should need to lock anything, I just want to read the data. Is
there anything I can do to fix this?
Read "Analyzing Deadlocks with SQL Server Profiler" in BOL.
http://sqlserver-tips.blogspot.com/|||Try using
select * from table (NOLOCK)
where xxxx = xxxx
This will not lock the database as it reads.
"Altman" <baltman@.easy-automation.comwrote in message
news:1182518265.867797.118630@.k79g2000hse.googlegr oups.com...
Quote:
Originally Posted by
>I have a customer using our program with SQL server and is
occasionally getting a "Transaction (process ID xxxxx) was deadlocked
on lock resources with another process and has been chosen as the
deadlock victim." From what they are telling me, there shouldn't be
any deadlock happening as they say this happens when they invoicing in
a different program that is accessing a different database. Also the
error is happening on an SQL Select from a view and this select is
then showing data in an HTML table for the user. I don't think this
view should need to lock anything, I just want to read the data. Is
there anything I can do to fix this?
>
Quote:
Originally Posted by
Try using
select * from table (NOLOCK)
where xxxx = xxxx
This will not lock the database as it reads.
This may on the other hand lead to that the query returns incorrect
results, which may even more seroius. There are situations where NOLOCK
is called for, but you need to understand the implications. If you
don't - don't try it.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||On Jun 23, 4:10 am, Erland Sommarskog <esq...@.sommarskog.sewrote:
Quote:
Originally Posted by
Oscar Santiesteban (o_santieste...@.bellsouth.net) writes:
Quote:
Originally Posted by
Try using
select * from table (NOLOCK)
where xxxx = xxxx
This will not lock the database as it reads.
>
This may on the other hand lead to that the query returns incorrect
results, which may even more seroius. There are situations where NOLOCK
is called for, but you need to understand the implications. If you
don't - don't try it.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
I Think that the nolock will work for me. I understand the
implications and I think that my program will be able to handle it.
What I would've liked better was something like read committed but
didn't lock records.|||On Jun 26, 10:30 am, Altman <balt...@.easy-automation.comwrote:
Quote:
Originally Posted by
On Jun 23, 4:10 am, Erland Sommarskog <esq...@.sommarskog.sewrote:
>
>
>
Quote:
Originally Posted by
Oscar Santiesteban (o_santieste...@.bellsouth.net) writes:
Quote:
Originally Posted by
Try using
select * from table (NOLOCK)
where xxxx = xxxx
This will not lock the database as it reads.
>
Quote:
Originally Posted by
This may on the other hand lead to that the query returns incorrect
results, which may even more seroius. There are situations where NOLOCK
is called for, but you need to understand the implications. If you
don't - don't try it.
>
Quote:
Originally Posted by
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Quote:
Originally Posted by
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
>
I Think that the nolock will work for me. I understand the
implications and I think that my program will be able to handle it.
What I would've liked better was something like read committed but
didn't lock records.
If you are on 2005, consider snapshot isolation.
http://sqlserver-tips.blogspot.com
Wednesday, March 21, 2012
deadlock on parent-child relationship
I have a program that inserts a row to a parent table and before it
commits then calls another program to insert rows to the child table.
This is causing a deadlock. When I looked at it, the
first program has an X lock on the primary key of the parent table and
the second program is trying to get a share lock on the index of the
parent table ?
Why is this happening ? How can I avoid it ?
Thanks
RogerMake sure the order of the tables in the from clause is the same in both
queries and consider using the UPDLOCK table hint.
Read more here:
http://msdn.microsoft.com/library/d... />
a_8i93.asp
http://msdn.microsoft.com/library/d... />
a_3hdf.asp
ML
http://milambda.blogspot.com/|||You can't avoid it unless both updates occur on the same connection, or
unless you bind the second connection to the first. Look up sp_bindsession
in BOL. Exclusive locks are held on an inserted row until it is committed,
so no other transaction can see the row until it's committed (unless you use
WITH(NOLOCK), which should be avoided whenever possible).
I prefer to dump an update that contains related information into temp
tables so that they can be committed using set-based operations within a
stored procedure, but that can have performance and scalability implications
depending on whether tempdb is on it's own disk subsystem and on whether
there's enough memory so that the contents of the temp tables aren't
migrated out to disk. Set-based operations minimize lock duration, index
maintenance and transaction logging, so it's a trade-off. Without testing,
it cannot be determined which method provides the best performance and
scalability for a particular update scenario. However, I prefer to keep
transaction processing within stored procedures because I've found that
troubleshooting and repairing blocking and deadlock problems is less
expensive if all transactions are contained in procedures. It's a lot
easier to add a SELECT WITH(UPDLOCK) to a stored procedure than to alter,
recompile, and redeploy a client program.
"Roger" <wonderinguys@.gmail.com> wrote in message
news:1138809010.484456.142920@.z14g2000cwz.googlegroups.com...
>I have a program that inserts a row to a parent table and before it
> commits then calls another program to insert rows to the child table.
> This is causing a deadlock. When I looked at it, the
> first program has an X lock on the primary key of the parent table and
> the second program is trying to get a share lock on the index of the
> parent table ?
> Why is this happening ? How can I avoid it ?
> Thanks
> Roger
>|||the program that inserts the child table is in a new spid...a different
one from the parent program. Why is that ? i am from DB2 running on
mainframe where this never happens. So need some help with this.|||On 2 Feb 2006 12:21:33 -0800, Roger wrote:
>the program that inserts the child table is in a new spid...a different
>one from the parent program. Why is that ? i am from DB2 running on
>mainframe where this never happens. So need some help with this.
Hi Roger,
That's the cause of your deadlock, then.
This surely doesn't happen automatically. In fact, you have to work
pretty hard to get a subprocedure to run in a different spid in SQL
Server. (Doing it from the client is easier, but still takes some
effort).
Can you post (snippets of) your code?
Hugo Kornelis, SQL Server MVP
commits then calls another program to insert rows to the child table.
This is causing a deadlock. When I looked at it, the
first program has an X lock on the primary key of the parent table and
the second program is trying to get a share lock on the index of the
parent table ?
Why is this happening ? How can I avoid it ?
Thanks
RogerMake sure the order of the tables in the from clause is the same in both
queries and consider using the UPDLOCK table hint.
Read more here:
http://msdn.microsoft.com/library/d... />
a_8i93.asp
http://msdn.microsoft.com/library/d... />
a_3hdf.asp
ML
http://milambda.blogspot.com/|||You can't avoid it unless both updates occur on the same connection, or
unless you bind the second connection to the first. Look up sp_bindsession
in BOL. Exclusive locks are held on an inserted row until it is committed,
so no other transaction can see the row until it's committed (unless you use
WITH(NOLOCK), which should be avoided whenever possible).
I prefer to dump an update that contains related information into temp
tables so that they can be committed using set-based operations within a
stored procedure, but that can have performance and scalability implications
depending on whether tempdb is on it's own disk subsystem and on whether
there's enough memory so that the contents of the temp tables aren't
migrated out to disk. Set-based operations minimize lock duration, index
maintenance and transaction logging, so it's a trade-off. Without testing,
it cannot be determined which method provides the best performance and
scalability for a particular update scenario. However, I prefer to keep
transaction processing within stored procedures because I've found that
troubleshooting and repairing blocking and deadlock problems is less
expensive if all transactions are contained in procedures. It's a lot
easier to add a SELECT WITH(UPDLOCK) to a stored procedure than to alter,
recompile, and redeploy a client program.
"Roger" <wonderinguys@.gmail.com> wrote in message
news:1138809010.484456.142920@.z14g2000cwz.googlegroups.com...
>I have a program that inserts a row to a parent table and before it
> commits then calls another program to insert rows to the child table.
> This is causing a deadlock. When I looked at it, the
> first program has an X lock on the primary key of the parent table and
> the second program is trying to get a share lock on the index of the
> parent table ?
> Why is this happening ? How can I avoid it ?
> Thanks
> Roger
>|||the program that inserts the child table is in a new spid...a different
one from the parent program. Why is that ? i am from DB2 running on
mainframe where this never happens. So need some help with this.|||On 2 Feb 2006 12:21:33 -0800, Roger wrote:
>the program that inserts the child table is in a new spid...a different
>one from the parent program. Why is that ? i am from DB2 running on
>mainframe where this never happens. So need some help with this.
Hi Roger,
That's the cause of your deadlock, then.
This surely doesn't happen automatically. In fact, you have to work
pretty hard to get a subprocedure to run in a different spid in SQL
Server. (Doing it from the client is easier, but still takes some
effort).
Can you post (snippets of) your code?
Hugo Kornelis, SQL Server MVP
Sunday, March 11, 2012
deadlock
Hi,
I have created a VB program to perform DTS tasks for data transfer from
ACCESS database to SQL Server. The DTS are created by saving the actual DTS
packages as VB file and used those bas files in VP app to run the DTS
programmatically.
The process works fine most of the time.
But occassionally the DTS process is getting locked. The two connections
from the DTS package to SQL server database gains DB lock on the database
and so the process does not go further .
Can any body know why this is happenning?
what could be the solution for this problem?
please help.
thanks
Sam
How are you sure it's a deadlock instead of a normal blocking?
You can set up trace flag -T1204 and -T3605 in the start up parameters on
the SQL server and capture deadlock details in the SQL error log. Or if you
have lumigent Log Explorer, you can set up alert on deadlocks. YOu can also
use SQL profiler to capture a trace using Locks:Deadlocks and Lock:Deadlock
Chain.
Richard
"Sam" <samirsoni@.hotmail.com> wrote in message
news:elDzAt6MFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have created a VB program to perform DTS tasks for data transfer from
> ACCESS database to SQL Server. The DTS are created by saving the actual
> DTS
> packages as VB file and used those bas files in VP app to run the DTS
> programmatically.
> The process works fine most of the time.
> But occassionally the DTS process is getting locked. The two connections
> from the DTS package to SQL server database gains DB lock on the database
> and so the process does not go further .
> Can any body know why this is happenning?
> what could be the solution for this problem?
> please help.
> thanks
> Sam
>
>
I have created a VB program to perform DTS tasks for data transfer from
ACCESS database to SQL Server. The DTS are created by saving the actual DTS
packages as VB file and used those bas files in VP app to run the DTS
programmatically.
The process works fine most of the time.
But occassionally the DTS process is getting locked. The two connections
from the DTS package to SQL server database gains DB lock on the database
and so the process does not go further .
Can any body know why this is happenning?
what could be the solution for this problem?
please help.
thanks
Sam
How are you sure it's a deadlock instead of a normal blocking?
You can set up trace flag -T1204 and -T3605 in the start up parameters on
the SQL server and capture deadlock details in the SQL error log. Or if you
have lumigent Log Explorer, you can set up alert on deadlocks. YOu can also
use SQL profiler to capture a trace using Locks:Deadlocks and Lock:Deadlock
Chain.
Richard
"Sam" <samirsoni@.hotmail.com> wrote in message
news:elDzAt6MFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have created a VB program to perform DTS tasks for data transfer from
> ACCESS database to SQL Server. The DTS are created by saving the actual
> DTS
> packages as VB file and used those bas files in VP app to run the DTS
> programmatically.
> The process works fine most of the time.
> But occassionally the DTS process is getting locked. The two connections
> from the DTS package to SQL server database gains DB lock on the database
> and so the process does not go further .
> Can any body know why this is happenning?
> what could be the solution for this problem?
> please help.
> thanks
> Sam
>
>
Thursday, March 8, 2012
deadlock
Hi,
I have created a VB program to perform DTS tasks for data transfer from
ACCESS database to SQL Server. The DTS are created by saving the actual DTS
packages as VB file and used those bas files in VP app to run the DTS
programmatically.
The process works fine most of the time.
But occassionally the DTS process is getting locked. The two connections
from the DTS package to SQL server database gains DB lock on the database
and so the process does not go further .
Can any body know why this is happenning?
what could be the solution for this problem?
please help.
thanks
SamHow are you sure it's a deadlock instead of a normal blocking?
You can set up trace flag -T1204 and -T3605 in the start up parameters on
the SQL server and capture deadlock details in the SQL error log. Or if you
have lumigent Log Explorer, you can set up alert on deadlocks. YOu can also
use SQL profiler to capture a trace using Locks:Deadlocks and Lock:Deadlock
Chain.
Richard
"Sam" <samirsoni@.hotmail.com> wrote in message
news:elDzAt6MFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have created a VB program to perform DTS tasks for data transfer from
> ACCESS database to SQL Server. The DTS are created by saving the actual
> DTS
> packages as VB file and used those bas files in VP app to run the DTS
> programmatically.
> The process works fine most of the time.
> But occassionally the DTS process is getting locked. The two connections
> from the DTS package to SQL server database gains DB lock on the database
> and so the process does not go further .
> Can any body know why this is happenning?
> what could be the solution for this problem?
> please help.
> thanks
> Sam
>
>
I have created a VB program to perform DTS tasks for data transfer from
ACCESS database to SQL Server. The DTS are created by saving the actual DTS
packages as VB file and used those bas files in VP app to run the DTS
programmatically.
The process works fine most of the time.
But occassionally the DTS process is getting locked. The two connections
from the DTS package to SQL server database gains DB lock on the database
and so the process does not go further .
Can any body know why this is happenning?
what could be the solution for this problem?
please help.
thanks
SamHow are you sure it's a deadlock instead of a normal blocking?
You can set up trace flag -T1204 and -T3605 in the start up parameters on
the SQL server and capture deadlock details in the SQL error log. Or if you
have lumigent Log Explorer, you can set up alert on deadlocks. YOu can also
use SQL profiler to capture a trace using Locks:Deadlocks and Lock:Deadlock
Chain.
Richard
"Sam" <samirsoni@.hotmail.com> wrote in message
news:elDzAt6MFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have created a VB program to perform DTS tasks for data transfer from
> ACCESS database to SQL Server. The DTS are created by saving the actual
> DTS
> packages as VB file and used those bas files in VP app to run the DTS
> programmatically.
> The process works fine most of the time.
> But occassionally the DTS process is getting locked. The two connections
> from the DTS package to SQL server database gains DB lock on the database
> and so the process does not go further .
> Can any body know why this is happenning?
> what could be the solution for this problem?
> please help.
> thanks
> Sam
>
>
deadlock
Hi,
I have created a VB program to perform DTS tasks for data transfer from
ACCESS database to SQL Server. The DTS are created by saving the actual DTS
packages as VB file and used those bas files in VP app to run the DTS
programmatically.
The process works fine most of the time.
But occassionally the DTS process is getting locked. The two connections
from the DTS package to SQL server database gains DB lock on the database
and so the process does not go further .
Can any body know why this is happenning?
what could be the solution for this problem?
please help.
thanks
SamHow are you sure it's a deadlock instead of a normal blocking?
You can set up trace flag -T1204 and -T3605 in the start up parameters on
the SQL server and capture deadlock details in the SQL error log. Or if you
have lumigent Log Explorer, you can set up alert on deadlocks. YOu can also
use SQL profiler to capture a trace using Locks:Deadlocks and Lock:Deadlock
Chain.
Richard
"Sam" <samirsoni@.hotmail.com> wrote in message
news:elDzAt6MFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have created a VB program to perform DTS tasks for data transfer from
> ACCESS database to SQL Server. The DTS are created by saving the actual
> DTS
> packages as VB file and used those bas files in VP app to run the DTS
> programmatically.
> The process works fine most of the time.
> But occassionally the DTS process is getting locked. The two connections
> from the DTS package to SQL server database gains DB lock on the database
> and so the process does not go further .
> Can any body know why this is happenning?
> what could be the solution for this problem?
> please help.
> thanks
> Sam
>
>
I have created a VB program to perform DTS tasks for data transfer from
ACCESS database to SQL Server. The DTS are created by saving the actual DTS
packages as VB file and used those bas files in VP app to run the DTS
programmatically.
The process works fine most of the time.
But occassionally the DTS process is getting locked. The two connections
from the DTS package to SQL server database gains DB lock on the database
and so the process does not go further .
Can any body know why this is happenning?
what could be the solution for this problem?
please help.
thanks
SamHow are you sure it's a deadlock instead of a normal blocking?
You can set up trace flag -T1204 and -T3605 in the start up parameters on
the SQL server and capture deadlock details in the SQL error log. Or if you
have lumigent Log Explorer, you can set up alert on deadlocks. YOu can also
use SQL profiler to capture a trace using Locks:Deadlocks and Lock:Deadlock
Chain.
Richard
"Sam" <samirsoni@.hotmail.com> wrote in message
news:elDzAt6MFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have created a VB program to perform DTS tasks for data transfer from
> ACCESS database to SQL Server. The DTS are created by saving the actual
> DTS
> packages as VB file and used those bas files in VP app to run the DTS
> programmatically.
> The process works fine most of the time.
> But occassionally the DTS process is getting locked. The two connections
> from the DTS package to SQL server database gains DB lock on the database
> and so the process does not go further .
> Can any body know why this is happenning?
> what could be the solution for this problem?
> please help.
> thanks
> Sam
>
>
Friday, February 17, 2012
DBNMPNTW Access Denied Problem
Hi all
I have a program that accesses SQL 2000 that is running on a win2003 machine. The program works on my XP machine but does not work on my win98 machine, I have even opened up a port on the server so the database can be accessed externally (This seems to work fine as well, a friend of mine tested it for me).
The error message returned on the win98 machine is "[DBNMPNTW] Access Denied". Please help, thank you.
James :(I don't suppose you're on a domain are you? If not, try adding the win98 user computer\user to SQL Server as a user.|||Hi
I have managed to fix the problem. Yes i am on a domain, and my win98 machine can log onto AD (i installed AD client).
I simply added an extra field in my connection string and it worked, it's something to do with network, found it on the net somewhere.
James :)
I have a program that accesses SQL 2000 that is running on a win2003 machine. The program works on my XP machine but does not work on my win98 machine, I have even opened up a port on the server so the database can be accessed externally (This seems to work fine as well, a friend of mine tested it for me).
The error message returned on the win98 machine is "[DBNMPNTW] Access Denied". Please help, thank you.
James :(I don't suppose you're on a domain are you? If not, try adding the win98 user computer\user to SQL Server as a user.|||Hi
I have managed to fix the problem. Yes i am on a domain, and my win98 machine can log onto AD (i installed AD client).
I simply added an extra field in my connection string and it worked, it's something to do with network, found it on the net somewhere.
James :)
dbnmpipe.exe for MS-DOS
I recently purchased sql 2000.
I need connectivity for an old DOS program.
I see that I need the file DBNMPIPE.EXE
I can't find this file anywhere on my CD's or on
Microsofts website.
Where can I get it?
"Cash Woodward" <cash@.grandtarghee.com> wrote in message
news:1f67801c457c1$bfc79810$a501280a@.phx.gbl...
> I recently purchased sql 2000.
> I need connectivity for an old DOS program.
> I see that I need the file DBNMPIPE.EXE
> I can't find this file anywhere on my CD's or on
> Microsofts website.
> Where can I get it?
I believe you are in non-supported territory here (from the SQL Server web
site):
Client Support:
.. Windows 955, Windows 98, Windows Me, Windows NT Workstation 4.0, Windows
2000 Professional, Windows XP Professional, and Windows XP Home Edition are
supported.
Steve
|||Actually it states that older clients will still work with sql 2000.
"Steve Thompson" wrote:
> "Cash Woodward" <cash@.grandtarghee.com> wrote in message
> news:1f67801c457c1$bfc79810$a501280a@.phx.gbl...
> I believe you are in non-supported territory here (from the SQL Server web
> site):
> Client Support:
> .. Windows 955, Windows 98, Windows Me, Windows NT Workstation 4.0, Windows
> 2000 Professional, Windows XP Professional, and Windows XP Home Edition are
> supported.
> Steve
>
>
|||Sent by email
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvforu...?SRV=MSDevApps
(faqxxx.zip in lib 7)
or http://www.ntfaq.com/Articles/Index...partmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faq
|||Older DOS based clients? Can you send a reference?
Thanks, Steve
"Cash Woodward" <Cash Woodward@.discussions.microsoft.com> wrote in message
news:7ECE2A36-195D-4120-9D4F-A94142E311A0@.microsoft.com...[vbcol=seagreen]
> Actually it states that older clients will still work with sql 2000.
> "Steve Thompson" wrote:
web[vbcol=seagreen]
Windows[vbcol=seagreen]
are[vbcol=seagreen]
|||See the reply #4 from Neil Pike.
This is from archive file SQL7DBLIBSUPPORT.TXT
This is what I have read from Microsofts website also.
Q. Does SQL 7/2000 support DB-Library? What about 16-bit clients - DOS
etc.?
A. Yes it does, but DB-Library is functionally stabilised at the 6.5
level. Therefore if a DB-Library client on whatever platform worked
against a 6.5 database it should work against the same database migrated
to SQL 7.0/2000.
None of the SQL 7.0 features like unicode, character columns greater
than 255 characters etc. are in DB-Library though. So if you utilise
any SQL 7.0 features then these can only be accessed by ODBC 3.7 or
OLE-DB clients.
Similarly for 16-bit clients. These are supported, but only with the
6.5 levels of ODBC/DB-Library code. 16-bit clients cannot access new
SQL 7.0 features either.
The 16-bit client code is not supplied with 7.0/2000 - you will have to
get it from the 6.5 CD-ROM. This includes DOS and Win 3.x drivers.
===
v1.03 2000.04.28
Applies to SQL Server versions : 7.0, 2000
FAQ Categories : Connectivity
Related FAQ articles : n/a
Related Microsoft Kb articles : n/a
Other related information : n/a
Authors : Neil Pike
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
|||Thank you Cash -- very interesting!
"Cash Woodward" <cash@.grandtarghee.com> wrote in message
news:%23ggDDuSWEHA.1164@.tk2msftngp13.phx.gbl...
> See the reply #4 from Neil Pike.
> This is from archive file SQL7DBLIBSUPPORT.TXT
> This is what I have read from Microsofts website also.
> Q. Does SQL 7/2000 support DB-Library? What about 16-bit clients - DOS
> etc.?
> A. Yes it does, but DB-Library is functionally stabilised at the 6.5
> level. Therefore if a DB-Library client on whatever platform worked
> against a 6.5 database it should work against the same database migrated
> to SQL 7.0/2000.
> None of the SQL 7.0 features like unicode, character columns greater
> than 255 characters etc. are in DB-Library though. So if you utilise
> any SQL 7.0 features then these can only be accessed by ODBC 3.7 or
> OLE-DB clients.
> Similarly for 16-bit clients. These are supported, but only with the
> 6.5 levels of ODBC/DB-Library code. 16-bit clients cannot access new
> SQL 7.0 features either.
> The 16-bit client code is not supplied with 7.0/2000 - you will have to
> get it from the 6.5 CD-ROM. This includes DOS and Win 3.x drivers.
> ===
> v1.03 2000.04.28
> Applies to SQL Server versions : 7.0, 2000
> FAQ Categories : Connectivity
> Related FAQ articles : n/a
> Related Microsoft Kb articles : n/a
> Other related information : n/a
> Authors : Neil Pike
>
>
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it!
I need connectivity for an old DOS program.
I see that I need the file DBNMPIPE.EXE
I can't find this file anywhere on my CD's or on
Microsofts website.
Where can I get it?
"Cash Woodward" <cash@.grandtarghee.com> wrote in message
news:1f67801c457c1$bfc79810$a501280a@.phx.gbl...
> I recently purchased sql 2000.
> I need connectivity for an old DOS program.
> I see that I need the file DBNMPIPE.EXE
> I can't find this file anywhere on my CD's or on
> Microsofts website.
> Where can I get it?
I believe you are in non-supported territory here (from the SQL Server web
site):
Client Support:
.. Windows 955, Windows 98, Windows Me, Windows NT Workstation 4.0, Windows
2000 Professional, Windows XP Professional, and Windows XP Home Edition are
supported.
Steve
|||Actually it states that older clients will still work with sql 2000.
"Steve Thompson" wrote:
> "Cash Woodward" <cash@.grandtarghee.com> wrote in message
> news:1f67801c457c1$bfc79810$a501280a@.phx.gbl...
> I believe you are in non-supported territory here (from the SQL Server web
> site):
> Client Support:
> .. Windows 955, Windows 98, Windows Me, Windows NT Workstation 4.0, Windows
> 2000 Professional, Windows XP Professional, and Windows XP Home Edition are
> supported.
> Steve
>
>
|||Sent by email
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvforu...?SRV=MSDevApps
(faqxxx.zip in lib 7)
or http://www.ntfaq.com/Articles/Index...partmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faq
|||Older DOS based clients? Can you send a reference?
Thanks, Steve
"Cash Woodward" <Cash Woodward@.discussions.microsoft.com> wrote in message
news:7ECE2A36-195D-4120-9D4F-A94142E311A0@.microsoft.com...[vbcol=seagreen]
> Actually it states that older clients will still work with sql 2000.
> "Steve Thompson" wrote:
web[vbcol=seagreen]
Windows[vbcol=seagreen]
are[vbcol=seagreen]
|||See the reply #4 from Neil Pike.
This is from archive file SQL7DBLIBSUPPORT.TXT
This is what I have read from Microsofts website also.
Q. Does SQL 7/2000 support DB-Library? What about 16-bit clients - DOS
etc.?
A. Yes it does, but DB-Library is functionally stabilised at the 6.5
level. Therefore if a DB-Library client on whatever platform worked
against a 6.5 database it should work against the same database migrated
to SQL 7.0/2000.
None of the SQL 7.0 features like unicode, character columns greater
than 255 characters etc. are in DB-Library though. So if you utilise
any SQL 7.0 features then these can only be accessed by ODBC 3.7 or
OLE-DB clients.
Similarly for 16-bit clients. These are supported, but only with the
6.5 levels of ODBC/DB-Library code. 16-bit clients cannot access new
SQL 7.0 features either.
The 16-bit client code is not supplied with 7.0/2000 - you will have to
get it from the 6.5 CD-ROM. This includes DOS and Win 3.x drivers.
===
v1.03 2000.04.28
Applies to SQL Server versions : 7.0, 2000
FAQ Categories : Connectivity
Related FAQ articles : n/a
Related Microsoft Kb articles : n/a
Other related information : n/a
Authors : Neil Pike
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
|||Thank you Cash -- very interesting!
"Cash Woodward" <cash@.grandtarghee.com> wrote in message
news:%23ggDDuSWEHA.1164@.tk2msftngp13.phx.gbl...
> See the reply #4 from Neil Pike.
> This is from archive file SQL7DBLIBSUPPORT.TXT
> This is what I have read from Microsofts website also.
> Q. Does SQL 7/2000 support DB-Library? What about 16-bit clients - DOS
> etc.?
> A. Yes it does, but DB-Library is functionally stabilised at the 6.5
> level. Therefore if a DB-Library client on whatever platform worked
> against a 6.5 database it should work against the same database migrated
> to SQL 7.0/2000.
> None of the SQL 7.0 features like unicode, character columns greater
> than 255 characters etc. are in DB-Library though. So if you utilise
> any SQL 7.0 features then these can only be accessed by ODBC 3.7 or
> OLE-DB clients.
> Similarly for 16-bit clients. These are supported, but only with the
> 6.5 levels of ODBC/DB-Library code. 16-bit clients cannot access new
> SQL 7.0 features either.
> The 16-bit client code is not supplied with 7.0/2000 - you will have to
> get it from the 6.5 CD-ROM. This includes DOS and Win 3.x drivers.
> ===
> v1.03 2000.04.28
> Applies to SQL Server versions : 7.0, 2000
> FAQ Categories : Connectivity
> Related FAQ articles : n/a
> Related Microsoft Kb articles : n/a
> Other related information : n/a
> Authors : Neil Pike
>
>
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it!
Subscribe to:
Posts (Atom)