Hi all

We've had a Paradox 9 system running for years, 13 in fact. It has been
sending data to and from an SQL 2000 database for 4 years without any issues
other than being slightly slow due to the nature of the SQL box also being
a File / Print server.

This box is Windows 2000.

Over the weekend our techies moved the SQL databases onto an all singing,
all dancing SQL server, still 2000 running Windowd 2003.

Since then, all our SQL access to the server has been slooooow! I.e, taking
15-20 minutes to post a record when it used to take 30 seconds to a minute.

We're using native Paradox code to access these tables using Tcursors through
ODBC.

Can anyone shed any light as to why it has suddenly gone so slow considering
the new server is about 4 times better than the old?

I realise using TC's to read/write SQL tables is frowned upon (now I do!)
but it used to work fine on the old server.

We can find no major differences other than the CPU's (4 x Dual Core) compared
to old Dual Xeon and Windows (2k3 compared to 2k)

Please help if you can, I don't have much hair left and we're in the schtuck!

Thanks ever so much for any help!

Regards

Trevor

Hi Trevor,

Aside from the fact that Windows 2003 (SBS or not ?) has heaps of network
related bugs, I am guessing that the network protocol that you previously
used (probably netbeui) has changed (probably to TCP/IP).

If that is the case then you need to make the necessary changes to remove
the 200 m/s delay that now exists by default under Windows 2003. There is a
registry setting that does this, something like TCPDelAckTicks. From memory
this delay is per packet and so it would be a hefty overhead when there is a
large amount of communication between a workstation and the server - which
is especially the case in *most* circumstances where you are using Tcursors
via the BDE via ODBC.

If the registry entry is not present, then create it with a value of Zero
which will remove the delay. I also vaguely remember there is another TCP
delay which can be removed as well, perhaps someone else will jump in here
and remind us all what it is.

Leslie.

"Trevor" <trevor (AT) nospam (DOT) com> wrote

Hi Trevor,

Aside from the fact that Windows 2003 (SBS or not ?) has heaps of network
related bugs, I am guessing that the network protocol that you previously
used (probably netbeui) has changed (probably to TCP/IP).

If that is the case then you need to make the necessary changes to remove
the 200 m/s delay that now exists by default under Windows 2003. There is a
registry setting that does this, something like TCPDelAckTicks. From memory
this delay is per packet and so it would be a hefty overhead when there is a
large amount of communication between a workstation and the server - which
is especially the case in *most* circumstances where you are using Tcursors
via the BDE via ODBC.

If the registry entry is not present, then create it with a value of Zero
which will remove the delay. I also vaguely remember there is another TCP
delay which can be removed as well, perhaps someone else will jump in here
and remind us all what it is.

Leslie.

"Trevor" <trevor (AT) nospam (DOT) com> wrote

Hi Trevor,

Aside from the fact that Windows 2003 (SBS or not ?) has heaps of network
related bugs, I am guessing that the network protocol that you previously
used (probably netbeui) has changed (probably to TCP/IP).

If that is the case then you need to make the necessary changes to remove
the 200 m/s delay that now exists by default under Windows 2003. There is a
registry setting that does this, something like TCPDelAckTicks. From memory
this delay is per packet and so it would be a hefty overhead when there is a
large amount of communication between a workstation and the server - which
is especially the case in *most* circumstances where you are using Tcursors
via the BDE via ODBC.

If the registry entry is not present, then create it with a value of Zero
which will remove the delay. I also vaguely remember there is another TCP
delay which can be removed as well, perhaps someone else will jump in here
and remind us all what it is.

Leslie.

"Trevor" <trevor (AT) nospam (DOT) com> wrote

Hi Trevor,

Aside from the fact that Windows 2003 (SBS or not ?) has heaps of network
related bugs, I am guessing that the network protocol that you previously
used (probably netbeui) has changed (probably to TCP/IP).

If that is the case then you need to make the necessary changes to remove
the 200 m/s delay that now exists by default under Windows 2003. There is a
registry setting that does this, something like TCPDelAckTicks. From memory
this delay is per packet and so it would be a hefty overhead when there is a
large amount of communication between a workstation and the server - which
is especially the case in *most* circumstances where you are using Tcursors
via the BDE via ODBC.

If the registry entry is not present, then create it with a value of Zero
which will remove the delay. I also vaguely remember there is another TCP
delay which can be removed as well, perhaps someone else will jump in here
and remind us all what it is.

Leslie.

"Trevor" <trevor (AT) nospam (DOT) com> wrote

Hi Trevor,

Aside from the fact that Windows 2003 (SBS or not ?) has heaps of network
related bugs, I am guessing that the network protocol that you previously
used (probably netbeui) has changed (probably to TCP/IP).

If that is the case then you need to make the necessary changes to remove
the 200 m/s delay that now exists by default under Windows 2003. There is a
registry setting that does this, something like TCPDelAckTicks. From memory
this delay is per packet and so it would be a hefty overhead when there is a
large amount of communication between a workstation and the server - which
is especially the case in *most* circumstances where you are using Tcursors
via the BDE via ODBC.

If the registry entry is not present, then create it with a value of Zero
which will remove the delay. I also vaguely remember there is another TCP
delay which can be removed as well, perhaps someone else will jump in here
and remind us all what it is.

Leslie.

"Trevor" <trevor (AT) nospam (DOT) com> wrote

Hi Trevor,

Aside from the fact that Windows 2003 (SBS or not ?) has heaps of network
related bugs, I am guessing that the network protocol that you previously
used (probably netbeui) has changed (probably to TCP/IP).

If that is the case then you need to make the necessary changes to remove
the 200 m/s delay that now exists by default under Windows 2003. There is a
registry setting that does this, something like TCPDelAckTicks. From memory
this delay is per packet and so it would be a hefty overhead when there is a
large amount of communication between a workstation and the server - which
is especially the case in *most* circumstances where you are using Tcursors
via the BDE via ODBC.

If the registry entry is not present, then create it with a value of Zero
which will remove the delay. I also vaguely remember there is another TCP
delay which can be removed as well, perhaps someone else will jump in here
and remind us all what it is.

Leslie.

"Trevor" <trevor (AT) nospam (DOT) com> wrote

Hi Trevor,

Aside from the fact that Windows 2003 (SBS or not ?) has heaps of network
related bugs, I am guessing that the network protocol that you previously
used (probably netbeui) has changed (probably to TCP/IP).

If that is the case then you need to make the necessary changes to remove
the 200 m/s delay that now exists by default under Windows 2003. There is a
registry setting that does this, something like TCPDelAckTicks. From memory
this delay is per packet and so it would be a hefty overhead when there is a
large amount of communication between a workstation and the server - which
is especially the case in *most* circumstances where you are using Tcursors
via the BDE via ODBC.

If the registry entry is not present, then create it with a value of Zero
which will remove the delay. I also vaguely remember there is another TCP
delay which can be removed as well, perhaps someone else will jump in here
and remind us all what it is.

Leslie.

"Trevor" <trevor (AT) nospam (DOT) com> wrote

Leslie, thanks but this sadly did not fix our issue, although it did break
our Access systems I'm being told so the techies are removing it.

Any other ideas?

Regards

Trevor

Leslie, thanks but this sadly did not fix our issue, although it did break
our Access systems I'm being told so the techies are removing it.

Any other ideas?

Regards

Trevor