Delay command execution

Hi
Here is the setting: Clients connect to SQL Server 2000 via ADO.
Here is the problem: After a client's successful login, the SQL Server 2000
should delay the processing of the client-commands by, e.g., 1 sec. How do I
tell it to the SQL Server 2000?
Thanks in advance.
Adrianat the sql server side
WAITFOR DELAY '00:00:01'
But why would you need it. You can as well have the delay at the client side
.
-Omnibuzz (The SQL GC)
http://omnibuzz-sql.blogspot.com/|||Thank you.
Well, I know this command. But where precisely do I tell the SQL Server to
delay an incoming command?
A delay at the client-side would be fine as well. But now, how do I tell it
to the client (3rd-party, no source code)?
Basically, I need to delay only the first command of a client immediately
after the login, so that I can run a "login-script" for the client on the
server.
Adrian
"Omnibuzz" <Omnibuzz@.discussions.microsoft.com> wrote in message
news:669DA5C9-52D0-4AA4-B489-2E041F14F7DE@.microsoft.com...
> at the sql server side
> WAITFOR DELAY '00:00:01'
> But why would you need it. You can as well have the delay at the client
> side.
> --
> -Omnibuzz (The SQL GC)
> http://omnibuzz-sql.blogspot.com/
>|||> Well, I know this command. But where precisely do I tell the SQL Server to delay an incom
ing
> command?
There's no such setting in SQL Server.

> A delay at the client-side would be fine as well. But now, how do I tell i
t to the client
> (3rd-party, no source code)?
You would have to talk to the 3:rd party vendor about this...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Adrian" <adrian@.iai.uni-bonn.de> wrote in message news:eYlmvehjGHA.4344@.TK2MSFTNGP05.phx.g
bl...
> Thank you.
> Well, I know this command. But where precisely do I tell the SQL Server to
delay an incoming
> command?
> A delay at the client-side would be fine as well. But now, how do I tell i
t to the client
> (3rd-party, no source code)?
> Basically, I need to delay only the first command of a client immediately
after the login, so that
> I can run a "login-script" for the client on the server.
> Adrian
> "Omnibuzz" <Omnibuzz@.discussions.microsoft.com> wrote in message
> news:669DA5C9-52D0-4AA4-B489-2E041F14F7DE@.microsoft.com...
>|||That's bad news.
But...
I monitor login-events with a trace and process the events in a trigger,
which is attached to the trace-table. I need to keep the client waiting
until the trigger finishes. Is there any other way to do this?
Adrian
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:ez$y2shjGHA.4884@.TK2MSFTNGP03.phx.gbl...
> There's no such setting in SQL Server.
>
> You would have to talk to the 3:rd party vendor about this...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Adrian" <adrian@.iai.uni-bonn.de> wrote in message
> news:eYlmvehjGHA.4344@.TK2MSFTNGP05.phx.gbl...
>|||Adrian (adrian@.iai.uni-bonn.de) writes:
> That's bad news.
> But...
> I monitor login-events with a trace and process the events in a trigger,
> which is attached to the trace-table. I need to keep the client waiting
> until the trigger finishes. Is there any other way to do this?
Wait, this sounds dangerous. OK, I don't know the architecture of
this particular 3rd party tool. But most modern applications these
days opens a connection, submits a query or two and then close the
connection. Or rather, that is how the application code looks like.
Under the hood, the client API maintains a connection pool, so that
if the application reconnects soon enough, a connection will be
reused.
Nevertheless, a one-second delay on each login sounds like a bad idea
to me.
Maybe if you explain in more detail what you are trying on achieve and
why, we may come with suggestions.
Don't forget to tell which version of SQL Server you are using.
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.mspxsql

Define Printer in Report

I have a client who tells me in Access you could assign the printer directly to the report using PrtDevNames and PrtDevMode. Apparently it's true.

Can this be done in Reporting Services?

check out the section "Direct Client Printing" in this link:

http://www.microsoft.com/technet/prodtechnol/sql/2005/2005ssrs.mspx

Shyam

|||

Thank you for the response.

Although that is a nice feature in 2005 over 2000. It's not quite what I am looking for I don't think.

I want to be able to store which printer the report should be sent to when printed so the user does not have to, I am looking for the same functionality that is in Access I mentioned above.

Default Versus Named Instance

I think I see what you ar asking.
Without a client side alias to make the ServerName\InstanceName format look
like a default instance, older MDAC versions (2.6 and lower, I think) cannot
connect to a named instance. This is client library issue, not an
application issue.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Matt Tinney" <matt.tinney@.css-security.com> wrote in message
news:eeAQaxv$GHA.4292@.TK2MSFTNGP02.phx.gbl...
> When makes an application require the use of a default SQL instance versus
> named instances? If named instances are allowed with an application, how
> does one specify the specific instance to use?
>
An alternative would be to have the server use a dedicated port for the name
instanced, as opposed to dynamic ports, and then specify that in the Data
Source parameter:
MyServer,11291
Anthony Thomas

"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:eo$acrbAHHA.2328@.TK2MSFTNGP02.phx.gbl...
> I think I see what you ar asking.
> Without a client side alias to make the ServerName\InstanceName format
look
> like a default instance, older MDAC versions (2.6 and lower, I think)
cannot[vbcol=seagreen]
> connect to a named instance. This is client library issue, not an
> application issue.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Matt Tinney" <matt.tinney@.css-security.com> wrote in message
> news:eeAQaxv$GHA.4292@.TK2MSFTNGP02.phx.gbl...
versus
>

Default protocols ..

Hi everyone,
I have something weird with an SQL Client connection and the default
protocols.
I set the TCP has the only one default client protocol with the CLICONFG
tool. On most of the computers, when a client wants to connect to a server
with its IP (somewhere over Internet), it uses the default protocols
perfectly.
Let's say, ie : osql -S IP -U usedID -P password
BUT. Sometimes, it doesn't. if I add the port to the server ip, then it
works. But I don't want to (in fact, I can't do it into my distribued
application) !
osql -S IP,1433 -U usedID -P password
Of course, I checked the default port fort the TCP and it is the good one.
If a run a netstat to see what happens, I can see something like that :
TCP POSTE1:2612 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2613 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2614 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2615 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2616 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2617 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2618 IP:ms-sql-s TIME_WAIT
So, it uses the TCP, connects to the right port BUT does not makes the
connection. If I just add this f**** ,1433, then it connects fine to the
same port. Really crazy...
Does anyone have an idea please ?
Thanks a lot !
Patrick
Some low probability possibilities:
When you say, "I checked the default port fort the TCP and it is the good
one" did you mean you checked the default
port for TCP/IP in the Client Network Utility on the client that can't
connect?
And are you in a totally SQL Server 2000 environment? If your client has SQL
Server 2005 installed, you may be using the SQL Server Native Client, and
need to check the client protocol and port number using the SQL Server
Configuration Manager. If your server is SQL Server 2005 there are
additional things you can check, but it sounds like it's not.
Rick Byham (MSFT)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Patrick B." <patrick@.ikosoft.com> wrote in message
news:eOPhBmIyHHA.484@.TK2MSFTNGP06.phx.gbl...
> Hi everyone,
> I have something weird with an SQL Client connection and the default
> protocols.
> I set the TCP has the only one default client protocol with the CLICONFG
> tool. On most of the computers, when a client wants to connect to a server
> with its IP (somewhere over Internet), it uses the default protocols
> perfectly.
> Let's say, ie : osql -S IP -U usedID -P password
> BUT. Sometimes, it doesn't. if I add the port to the server ip, then it
> works. But I don't want to (in fact, I can't do it into my distribued
> application) !
> osql -S IP,1433 -U usedID -P password
> Of course, I checked the default port fort the TCP and it is the good one.
> If a run a netstat to see what happens, I can see something like that :
> TCP POSTE1:2612 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2613 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2614 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2615 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2616 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2617 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2618 IP:ms-sql-s TIME_WAIT
> So, it uses the TCP, connects to the right port BUT does not makes the
> connection. If I just add this f**** ,1433, then it connects fine to the
> same port. Really crazy...
> Does anyone have an idea please ?
> Thanks a lot !
> Patrick
>
|||Hi,
Thank you for you reply.
Yes, it is in a totally SQL Server 2000 environment, and every server has an
instance. And yes, I checked the default port in the Client Utility on the
client that can't connect.
I found new things, more and more weird.
On a client that can't connect, I tried with the local server (we install an
instancied MSDE with all of our softwares, and the configuration on clients
and servers are the same). The problem is exactly the same with the
localhost.
osql -S 127.0.0.1 -E ==> failed
osql -S 127.0.0.1\INSTANCENAME -E ==> ok
osql -S 127.0.0.1,1433 -E ==> ok
But on most pcs, those 3 cases are working perfectly ! I really don't
understand...
Thanks again,
Patrick
(sorry for my poor english !)
"Rick Byham, (MSFT)" <rickbyh@.REDMOND.CORP.MICROSOFT.COM> a crit dans le
message de news: 99849E87-A62F-40B7-AF97-567C1A3E9A6F@.microsoft.com...
> Some low probability possibilities:
> When you say, "I checked the default port fort the TCP and it is the good
> one" did you mean you checked the default
> port for TCP/IP in the Client Network Utility on the client that can't
> connect?
> And are you in a totally SQL Server 2000 environment? If your client has
> SQL Server 2005 installed, you may be using the SQL Server Native Client,
> and need to check the client protocol and port number using the SQL Server
> Configuration Manager. If your server is SQL Server 2005 there are
> additional things you can check, but it sounds like it's not.
> --
> Rick Byham (MSFT)
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Patrick B." <patrick@.ikosoft.com> wrote in message
> news:eOPhBmIyHHA.484@.TK2MSFTNGP06.phx.gbl...
>

Default protocols ..

Hi everyone,
I have something weird with an SQL Client connection and the default
protocols.
I set the TCP has the only one default client protocol with the CLICONFG
tool. On most of the computers, when a client wants to connect to a server
with its IP (somewhere over Internet), it uses the default protocols
perfectly.
Let's say, ie : osql -S IP -U usedID -P password
BUT. Sometimes, it doesn't. if I add the port to the server ip, then it
works. But I don't want to (in fact, I can't do it into my distribued
application) !
osql -S IP,1433 -U usedID -P password
Of course, I checked the default port fort the TCP and it is the good one.
If a run a netstat to see what happens, I can see something like that :
TCP POSTE1:2612 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2613 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2614 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2615 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2616 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2617 IP:ms-sql-s TIME_WAIT
TCP POSTE1:2618 IP:ms-sql-s TIME_WAIT
So, it uses the TCP, connects to the right port BUT does not makes the
connection. If I just add this f**** ,1433, then it connects fine to the
same port. Really crazy...
Does anyone have an idea please ?
Thanks a lot !
PatrickSome low probability possibilities:
When you say, "I checked the default port fort the TCP and it is the good
one" did you mean you checked the default
port for TCP/IP in the Client Network Utility on the client that can't
connect?
And are you in a totally SQL Server 2000 environment? If your client has SQL
Server 2005 installed, you may be using the SQL Server Native Client, and
need to check the client protocol and port number using the SQL Server
Configuration Manager. If your server is SQL Server 2005 there are
additional things you can check, but it sounds like it's not.
--
Rick Byham (MSFT)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Patrick B." <patrick@.ikosoft.com> wrote in message
news:eOPhBmIyHHA.484@.TK2MSFTNGP06.phx.gbl...
> Hi everyone,
> I have something weird with an SQL Client connection and the default
> protocols.
> I set the TCP has the only one default client protocol with the CLICONFG
> tool. On most of the computers, when a client wants to connect to a server
> with its IP (somewhere over Internet), it uses the default protocols
> perfectly.
> Let's say, ie : osql -S IP -U usedID -P password
> BUT. Sometimes, it doesn't. if I add the port to the server ip, then it
> works. But I don't want to (in fact, I can't do it into my distribued
> application) !
> osql -S IP,1433 -U usedID -P password
> Of course, I checked the default port fort the TCP and it is the good one.
> If a run a netstat to see what happens, I can see something like that :
> TCP POSTE1:2612 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2613 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2614 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2615 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2616 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2617 IP:ms-sql-s TIME_WAIT
> TCP POSTE1:2618 IP:ms-sql-s TIME_WAIT
> So, it uses the TCP, connects to the right port BUT does not makes the
> connection. If I just add this f**** ,1433, then it connects fine to the
> same port. Really crazy...
> Does anyone have an idea please ?
> Thanks a lot !
> Patrick
>|||Hi,
Thank you for you reply.
Yes, it is in a totally SQL Server 2000 environment, and every server has an
instance. And yes, I checked the default port in the Client Utility on the
client that can't connect.
I found new things, more and more weird.
On a client that can't connect, I tried with the local server (we install an
instancied MSDE with all of our softwares, and the configuration on clients
and servers are the same). The problem is exactly the same with the
localhost.
osql -S 127.0.0.1 -E ==> failed
osql -S 127.0.0.1\INSTANCENAME -E ==> ok
osql -S 127.0.0.1,1433 -E ==> ok
But on most pcs, those 3 cases are working perfectly ! I really don't
understand...
Thanks again,
Patrick
(sorry for my poor english !)
"Rick Byham, (MSFT)" <rickbyh@.REDMOND.CORP.MICROSOFT.COM> a crit dans le
message de news: 99849E87-A62F-40B7-AF97-567C1A3E9A6F@.microsoft.com...
> Some low probability possibilities:
> When you say, "I checked the default port fort the TCP and it is the good
> one" did you mean you checked the default
> port for TCP/IP in the Client Network Utility on the client that can't
> connect?
> And are you in a totally SQL Server 2000 environment? If your client has
> SQL Server 2005 installed, you may be using the SQL Server Native Client,
> and need to check the client protocol and port number using the SQL Server
> Configuration Manager. If your server is SQL Server 2005 there are
> additional things you can check, but it sounds like it's not.
> --
> Rick Byham (MSFT)
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Patrick B." <patrick@.ikosoft.com> wrote in message
> news:eOPhBmIyHHA.484@.TK2MSFTNGP06.phx.gbl...
>