MDF Files currupted: client

Showing posts with label client. Show all posts

Friday, March 30, 2012

named set questions

As I understand it, a named set is not processed until it is needed.

Once these are processed are they cached for use by other client requests?

If there are Aggregations set up in the cube will this trigger the named sets be processed right away with the cube?

I assume that if a named set is too big there could be loss in performance, is there a way to hold down the size of a named set?

here are some examples of named sets i've created using some calculated members. perhaps there is a better way of doing this?

*************** Calculated Members***************************

CREATE MEMBER CURRENTCUBE.[MEASURES].[HP Plus Addl Billing]

AS aggregate([PREP CONTROL HDR].[Bill Formats].&[19],[Measures].[Billed Sales Amount]),

FORMAT_STRING = "Currency",

VISIBLE = 1;

2nd calculated member

CREATE MEMBER CURRENTCUBE.[MEASURES].[Prep Billing]

AS AGGREGATE(EXCEPT([PREP CONTROL HDR].[Bill Formats].[Bill Formats] ,{[PREP CONTROL HDR].[Bill Formats].&[19],[PREP CONTROL HDR].[Bill Formats].&[7]}),[Measures].[Billed Sales Amount]),

FORMAT_STRING = "Currency",

VISIBLE = 1;

*******************named sets************************************

CREATE SET CURRENTCUBE.[CTP Customers]

AS FILTER([CUSTOMER JOB].[Title Name].[Title Name].members,([Job Complete Date].[Calendar Full],[Measures].[HP Plus Addl Billing])> 0 );

CREATE SET CURRENTCUBE.[Prep Customers]

AS FILTER([CUSTOMER JOB].[Title Name].[Title Name].members,([Job Complete Date].[Year].&[2005],[Measures].[Prep Billing]) > 5000 ) ;

This one, I've used other named sets to create another named set.

Is this a bad thing?

CREATE SET CURRENTCUBE.[Non-Prep-Photo Customers]

AS EXCEPT([CTP Customers],{[Prep Customers],[Photo Customers]});

As I understand it, a named set is not processed until it is needed.

Once these are processed are they cached for use by other client requests?

Actually no - named sets are always processed and evaluated during MDX Script execution. This is done once, and they are cached afterwards.

|||

We've had issues where after the cube was processed it was not available for running reports until the server was rebooted.

When we removed the named sets the issue went away.

Is there any issues related to using named sets on a 32bit server running sql server 2005?

Why would one choose Named Pipes over TCP/IP for the client net lib? We have
noticed for some of our customers that changing to named pipes speeds up the
response times of our application. But it is my understanding that a
properly configured LAN should work fine with TCP/IP.
Thanks,
Bob Castleman
SuccessWare SoftwareIt is my understanding that named pipes have slightly less overhead than
TCP/IP but there it is usually not enough to warrant using named pipes. TCP
is much more versatile and should be encouraged in general over named pipes.
One thing to note is that WIN2003 has a 25% higher throuput in TCP over
Win2000 and DNS lookups are up to 120% faster as well. If your clients are
looking for speed improvements and are not on Win2003 they should try it
out. Another thing to note is that usually when clients tell me one
protocol is faster than another I tend to find there is too much chatter
from the client to the server in the first place. The more packets sent
back and forth the more likely you will have performance issues under heavy
load.
--
Andrew J. Kelly SQL MVP
"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
> Thanks,
> Bob Castleman
> SuccessWare Software
>|||http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/optimsql/odp_tun_1a_7fcj.asp
Peter
"Status quo, you know, that is Latin for "the mess we're
in."
Ronald Reagan
>--Original Message--
>Why would one choose Named Pipes over TCP/IP for the
client net lib? We have
>noticed for some of our customers that changing to named
pipes speeds up the
>response times of our application. But it is my
understanding that a
>properly configured LAN should work fine with TCP/IP.
>Thanks,
>Bob Castleman
>SuccessWare Software
>
>.
>|||A specific example of what we are running into happened this morning. A
customer called complaining of speed problems. Everything was "fine" on
Friday and today it was slow. CPU load on the database server was around 2%.
Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
Named Pipes and the time it took to load our application went from 20
seconds to 2 seconds. He reported a similar effect on the other
workstations. Nothing I have been able to find about TCP/IP and Named Pipes
would explain this behavior. This seems like some problem in network
communication, especially since the server was basically sitting idle.
I personally don't like "quick fixes". We run into this with just enough
regularity that it would be good to know what's really happening so we can
address the underlying problem.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
> have
>> noticed for some of our customers that changing to named pipes speeds up
> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>|||Simply some facts top start with: Named Pipes is a OSI level 7 (Application)
protocol, WinSock is OSI level 5 (Session), therefore in a TCP only based
network, Named Pipes actually goes over WinSock, so it does not make any
sense that TCP Winsock is slower in that case, which is also not the
experience, and this is why we use TCP to perform client server benchmarks
for SQL Server. When running on the same machine, Named Pipes is faster then
TCP, because it becomes a Local Pipe call (this is where the magic . (dot)
notation is coming from).
Also since Named Pipes are file system objects at kernel level the
scalability compared to WinSock is much less, which is why if you need to
handle large number of connections you always have to use TCP sockets
instead of named pipes. Which each OS release thresholds move, like Andrew
said in Windows Server 2003, TCP sockets and DNS performance increase
dramatically. For example in NT 4.0 you would run out of file handles when
you would have more then 100-150 named pipes connections, this is not longer
a problem with Windows 2000 and Windows Server 2004, but this is to indicate
that each protocol have there own characteristics and scalability
thresholds.
In general the default choice is and should be TCP sockets for all remote
connections, if you are running on the same server like batch process you
might consider named pipes using a local pipe (using the . (dot) notation).
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
> have
>> noticed for some of our customers that changing to named pipes speeds up
> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>|||Anti.virus program trying to AV check the named pipes stuff?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Castleman" <nomail@.here> wrote in message news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>A specific example of what we are running into happened this morning. A customer called complaining
>of speed problems. Everything was "fine" on Friday and today it was slow. CPU load on the database
>server was around 2%. Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
>Named Pipes and the time it took to load our application went from 20 seconds to 2 seconds. He
>reported a similar effect on the other workstations. Nothing I have been able to find about TCP/IP
>and Named Pipes would explain this behavior. This seems like some problem in network communication,
>especially since the server was basically sitting idle.
> I personally don't like "quick fixes". We run into this with just enough regularity that it would
> be good to know what's really happening so we can address the underlying problem.
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> It is my understanding that named pipes have slightly less overhead than
>> TCP/IP but there it is usually not enough to warrant using named pipes. TCP
>> is much more versatile and should be encouraged in general over named pipes.
>> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
>> Win2000 and DNS lookups are up to 120% faster as well. If your clients are
>> looking for speed improvements and are not on Win2003 they should try it
>> out. Another thing to note is that usually when clients tell me one
>> protocol is faster than another I tend to find there is too much chatter
>> from the client to the server in the first place. The more packets sent
>> back and forth the more likely you will have performance issues under heavy
>> load.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Bob Castleman" <nomail@.here> wrote in message
>> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
>> have
>> noticed for some of our customers that changing to named pipes speeds up
>> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>>
>|||An other option we see often are a DNS name resolution problems, use tracert
to determine the route taken.
An other thought are these notebooks, that connect wireless as well, or at
home? In which case it most of the times helps to dump the DNS resolver
cache of the workstation. See IPCONFIG /flushdns
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> Anti.virus program trying to AV check the named pipes stuff?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>>A specific example of what we are running into happened this morning. A
>>customer called complaining of speed problems. Everything was "fine" on
>>Friday and today it was slow. CPU load on the database server was around
>>2%. Disks weren't thrasing, etc. I had him change a workstation from
>>TCP/IP to Named Pipes and the time it took to load our application went
>>from 20 seconds to 2 seconds. He reported a similar effect on the other
>>workstations. Nothing I have been able to find about TCP/IP and Named
>>Pipes would explain this behavior. This seems like some problem in network
>>communication, especially since the server was basically sitting idle.
>> I personally don't like "quick fixes". We run into this with just enough
>> regularity that it would be good to know what's really happening so we
>> can address the underlying problem.
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> It is my understanding that named pipes have slightly less overhead than
>> TCP/IP but there it is usually not enough to warrant using named pipes.
>> TCP
>> is much more versatile and should be encouraged in general over named
>> pipes.
>> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
>> Win2000 and DNS lookups are up to 120% faster as well. If your clients
>> are
>> looking for speed improvements and are not on Win2003 they should try it
>> out. Another thing to note is that usually when clients tell me one
>> protocol is faster than another I tend to find there is too much chatter
>> from the client to the server in the first place. The more packets sent
>> back and forth the more likely you will have performance issues under
>> heavy
>> load.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Bob Castleman" <nomail@.here> wrote in message
>> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
>> have
>> noticed for some of our customers that changing to named pipes speeds
>> up
>> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>>
>>
>|||"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
Don't know if this is your problem, but there was a bug a while ago in SQL
Server 2000 to do with the introduction of Kerberos aware authentication
using DBLibrary connections over TCP/IP.
IIRC, the SQL Client and SQL Server would not correctly negotiate packet
sizes. This could be circumvented by explicitly overriding the default
packet size in the client app. This was resolved in SQL Server SP2.
Kind Regards, Howard|||Yes I have seen where issues with DNS have caused situations such as this as
well.
--
Andrew J. Kelly SQL MVP
"Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
> An other option we see often are a DNS name resolution problems, use
tracert
> to determine the route taken.
> An other thought are these notebooks, that connect wireless as well, or at
> home? In which case it most of the times helps to dump the DNS resolver
> cache of the workstation. See IPCONFIG /flushdns
> GertD@.SQLDev.Net
> Please reply only to the newsgroups.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> You assume all risk for your use.
> Copyright © SQLDev.Net 1991-2004 All rights reserved.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> > Anti.virus program trying to AV check the named pipes stuff?
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bob Castleman" <nomail@.here> wrote in message
> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
> >>A specific example of what we are running into happened this morning. A
> >>customer called complaining of speed problems. Everything was "fine" on
> >>Friday and today it was slow. CPU load on the database server was around
> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
> >>TCP/IP to Named Pipes and the time it took to load our application went
> >>from 20 seconds to 2 seconds. He reported a similar effect on the other
> >>workstations. Nothing I have been able to find about TCP/IP and Named
> >>Pipes would explain this behavior. This seems like some problem in
network
> >>communication, especially since the server was basically sitting idle.
> >>
> >> I personally don't like "quick fixes". We run into this with just
enough
> >> regularity that it would be good to know what's really happening so we
> >> can address the underlying problem.
> >>
> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> >> It is my understanding that named pipes have slightly less overhead
than
> >> TCP/IP but there it is usually not enough to warrant using named
pipes.
> >> TCP
> >> is much more versatile and should be encouraged in general over named
> >> pipes.
> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
over
> >> Win2000 and DNS lookups are up to 120% faster as well. If your
clients
> >> are
> >> looking for speed improvements and are not on Win2003 they should try
it
> >> out. Another thing to note is that usually when clients tell me one
> >> protocol is faster than another I tend to find there is too much
chatter
> >> from the client to the server in the first place. The more packets
sent
> >> back and forth the more likely you will have performance issues under
> >> heavy
> >> load.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "Bob Castleman" <nomail@.here> wrote in message
> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> >> Why would one choose Named Pipes over TCP/IP for the client net lib?
We
> >> have
> >> noticed for some of our customers that changing to named pipes speeds
> >> up
> >> the
> >> response times of our application. But it is my understanding that a
> >> properly configured LAN should work fine with TCP/IP.
> >>
> >> Thanks,
> >>
> >> Bob Castleman
> >> SuccessWare Software
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>|||Same here.
Basically if the DNS server is unavailable the client will wait for 20-30
seconds, and then resolve the servername in a different way.
You can do a quick check if this is the issue by connecting to the server
via both the IP-address and the servername. IP-address should behave
normally and the servername will have the 30 second delay.
--
Jacco Schalkwijk
SQL Server MVP
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
> Yes I have seen where issues with DNS have caused situations such as this
> as
> well.
> --
> Andrew J. Kelly SQL MVP
>
> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
>> An other option we see often are a DNS name resolution problems, use
> tracert
>> to determine the route taken.
>> An other thought are these notebooks, that connect wireless as well, or
>> at
>> home? In which case it most of the times helps to dump the DNS resolver
>> cache of the workstation. See IPCONFIG /flushdns
>> GertD@.SQLDev.Net
>> Please reply only to the newsgroups.
>> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>> You assume all risk for your use.
>> Copyright © SQLDev.Net 1991-2004 All rights reserved.
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in
>> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
>> > Anti.virus program trying to AV check the named pipes stuff?
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bob Castleman" <nomail@.here> wrote in message
>> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>> >>A specific example of what we are running into happened this morning. A
>> >>customer called complaining of speed problems. Everything was "fine" on
>> >>Friday and today it was slow. CPU load on the database server was
>> >>around
>> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
>> >>TCP/IP to Named Pipes and the time it took to load our application went
>> >>from 20 seconds to 2 seconds. He reported a similar effect on the other
>> >>workstations. Nothing I have been able to find about TCP/IP and Named
>> >>Pipes would explain this behavior. This seems like some problem in
> network
>> >>communication, especially since the server was basically sitting idle.
>> >>
>> >> I personally don't like "quick fixes". We run into this with just
> enough
>> >> regularity that it would be good to know what's really happening so we
>> >> can address the underlying problem.
>> >>
>> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> >> It is my understanding that named pipes have slightly less overhead
> than
>> >> TCP/IP but there it is usually not enough to warrant using named
> pipes.
>> >> TCP
>> >> is much more versatile and should be encouraged in general over named
>> >> pipes.
>> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
> over
>> >> Win2000 and DNS lookups are up to 120% faster as well. If your
> clients
>> >> are
>> >> looking for speed improvements and are not on Win2003 they should try
> it
>> >> out. Another thing to note is that usually when clients tell me one
>> >> protocol is faster than another I tend to find there is too much
> chatter
>> >> from the client to the server in the first place. The more packets
> sent
>> >> back and forth the more likely you will have performance issues under
>> >> heavy
>> >> load.
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >>
>> >> "Bob Castleman" <nomail@.here> wrote in message
>> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> >> Why would one choose Named Pipes over TCP/IP for the client net lib?
> We
>> >> have
>> >> noticed for some of our customers that changing to named pipes
>> >> speeds
>> >> up
>> >> the
>> >> response times of our application. But it is my understanding that a
>> >> properly configured LAN should work fine with TCP/IP.
>> >>
>> >> Thanks,
>> >>
>> >> Bob Castleman
>> >> SuccessWare Software
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>|||Thanks,
I'll try that.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid> wrote
in message news:uXQM9FQlEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Same here.
> Basically if the DNS server is unavailable the client will wait for 20-30
> seconds, and then resolve the servername in a different way.
> You can do a quick check if this is the issue by connecting to the server
> via both the IP-address and the servername. IP-address should behave
> normally and the servername will have the 30 second delay.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
>> Yes I have seen where issues with DNS have caused situations such as this
>> as
>> well.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
>> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
>> An other option we see often are a DNS name resolution problems, use
>> tracert
>> to determine the route taken.
>> An other thought are these notebooks, that connect wireless as well, or
>> at
>> home? In which case it most of the times helps to dump the DNS resolver
>> cache of the workstation. See IPCONFIG /flushdns
>> GertD@.SQLDev.Net
>> Please reply only to the newsgroups.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> You assume all risk for your use.
>> Copyright © SQLDev.Net 1991-2004 All rights reserved.
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in
>> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
>> > Anti.virus program trying to AV check the named pipes stuff?
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bob Castleman" <nomail@.here> wrote in message
>> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>> >>A specific example of what we are running into happened this morning.
>> >>A
>> >>customer called complaining of speed problems. Everything was "fine"
>> >>on
>> >>Friday and today it was slow. CPU load on the database server was
>> >>around
>> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
>> >>TCP/IP to Named Pipes and the time it took to load our application
>> >>went
>> >>from 20 seconds to 2 seconds. He reported a similar effect on the
>> >>other
>> >>workstations. Nothing I have been able to find about TCP/IP and Named
>> >>Pipes would explain this behavior. This seems like some problem in
>> network
>> >>communication, especially since the server was basically sitting idle.
>> >>
>> >> I personally don't like "quick fixes". We run into this with just
>> enough
>> >> regularity that it would be good to know what's really happening so
>> >> we
>> >> can address the underlying problem.
>> >>
>> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> >> It is my understanding that named pipes have slightly less overhead
>> than
>> >> TCP/IP but there it is usually not enough to warrant using named
>> pipes.
>> >> TCP
>> >> is much more versatile and should be encouraged in general over
>> >> named
>> >> pipes.
>> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
>> over
>> >> Win2000 and DNS lookups are up to 120% faster as well. If your
>> clients
>> >> are
>> >> looking for speed improvements and are not on Win2003 they should
>> >> try
>> it
>> >> out. Another thing to note is that usually when clients tell me one
>> >> protocol is faster than another I tend to find there is too much
>> chatter
>> >> from the client to the server in the first place. The more packets
>> sent
>> >> back and forth the more likely you will have performance issues
>> >> under
>> >> heavy
>> >> load.
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >>
>> >> "Bob Castleman" <nomail@.here> wrote in message
>> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> >> Why would one choose Named Pipes over TCP/IP for the client net
>> >> lib?
>> We
>> >> have
>> >> noticed for some of our customers that changing to named pipes
>> >> speeds
>> >> up
>> >> the
>> >> response times of our application. But it is my understanding that
>> >> a
>> >> properly configured LAN should work fine with TCP/IP.
>> >>
>> >> Thanks,
>> >>
>> >> Bob Castleman
>> >> SuccessWare Software
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>|||Bob,
Named-pipes is a "netbios" thing so it uses WINS (and LMHOSTS) to resolve
names.
TCP/IP Sockets uses DNS (and HOSTS).
Hence the reason DNS issues affect tcp-ip net-lib and not named-pipes net-lib.
(Even though both fundamentally run over tcp-ip. You can run named-pipes over
other protocols, but that's extremely rare these days)
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvforums/UK/default.asp?SRV=MSDevApps
(faqxxx.zip in lib 7)
or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faqsql

Named Pipes vs TCP

How would one go about adjusting the default connection to the SQL Server on the client side, using either Named Pipes or TCP as the default?Look for the Client Network Utility tool in the SQL Server program group. Or start->run CliConfig.exe.|||any way to pull of the defaulting programmatically??|||Yes, but the mechanics vary a lot depending on how you are programming. The easiest/surest way is to use the NETWORK parameter within DSN-Less connection strings (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnodbc/html/odbcsql.asp).

-PatP|||Looks like the ticket, thanks for your assistance...

named pipes under alias

I have a SQLSERVER INSTANCE A, to which I want to connect from a Client as TEST, using the SQL Server alias functionality under the client network utility program. The alias is working fine with the TCP\IP connection but it fails when I try to connect to the SQL Server using the named pipes. In my case I'm trying to connect to a named instance of SQL Server 2000 using the following pipe: \\servername\pipe\mssql$instancename\sql\query

Any help?I have just tried this. Pain in the neck, too. When you change the name of the alias, the client network utility is all helpful, and changes the actual path, and server name. So you have to get the right path, and save it of in notepad or something. Change the name of the alias, replace the name of the server with the name of the server you want, then recover the path from notepad. I tried it, and it did not work. Then I hit the Apply button. Now it works. Does that approximate what you went through?|||I can connect to any server using the alias name with the TCP/IP, but the same doesn't work with the Named Pipes.

Wednesday, March 28, 2012

Named Pipes

I have a SQL Server 2000 Enterprise Edition database with a Windows 2000
operating system. The Client Network Utility the protocols that are Enabled
are TCP/IP and Named Pipes.
TCP/IP is the first protocol in the list and second is Named Pipes.
Could Named Pipes in the Enable protocol list slow down the database or
connection performance?
Thank You,
If it's just the fact that the Named Pipes protocol is enabled, there
shouldn't be any performance implication. If you are talking about the
performance implication of using named pipes vs. using TCP/IP, I'm not aware
of any significant difference as of late, although there were some references
in the past (well, way back) about named pipes being less performant in some
cases (see http://support.microsoft.com/?kbid=156430 for an example. Note
that it's last reviewed in 2003)
In general, I prefer TCP/IP not because of any performance implication, but
for administrative convenience. For instance, names pipes depend on NetBIOS,
and require more ports through a firewall.
Linchi
"Joe K." wrote:

> I have a SQL Server 2000 Enterprise Edition database with a Windows 2000
> operating system. The Client Network Utility the protocols that are Enabled
> are TCP/IP and Named Pipes.
> TCP/IP is the first protocol in the list and second is Named Pipes.
> Could Named Pipes in the Enable protocol list slow down the database or
> connection performance?
> Thank You,
>

Named Pipes

I have a SQL Server 2000 Enterprise Edition database with a Windows 2000
operating system. The Client Network Utility the protocols that are Enabled
are TCP/IP and Named Pipes.
TCP/IP is the first protocol in the list and second is Named Pipes.
Could Named Pipes in the Enable protocol list slow down the database or
connection performance?
Thank You,If it's just the fact that the Named Pipes protocol is enabled, there
shouldn't be any performance implication. If you are talking about the
performance implication of using named pipes vs. using TCP/IP, I'm not aware
of any significant difference as of late, although there were some reference
s
in the past (well, way back) about named pipes being less performant in some
cases (see http://support.microsoft.com/?kbid=156430 for an example. Note
that it's last reviewed in 2003)
In general, I prefer TCP/IP not because of any performance implication, but
for administrative convenience. For instance, names pipes depend on NetBIOS,
and require more ports through a firewall.
Linchi
"Joe K." wrote:

> I have a SQL Server 2000 Enterprise Edition database with a Windows 2000
> operating system. The Client Network Utility the protocols that are Enabl
ed
> are TCP/IP and Named Pipes.
> TCP/IP is the first protocol in the list and second is Named Pipes.
> Could Named Pipes in the Enable protocol list slow down the database or
> connection performance?
> Thank You,
>

Named Pipes

I have a SQL Server 2000 Enterprise Edition database with a Windows 2000
operating system. The Client Network Utility the protocols that are Enabled
are TCP/IP and Named Pipes.
TCP/IP is the first protocol in the list and second is Named Pipes.
Could Named Pipes in the Enable protocol list slow down the database or
connection performance?
Thank You,If it's just the fact that the Named Pipes protocol is enabled, there
shouldn't be any performance implication. If you are talking about the
performance implication of using named pipes vs. using TCP/IP, I'm not aware
of any significant difference as of late, although there were some references
in the past (well, way back) about named pipes being less performant in some
cases (see http://support.microsoft.com/?kbid=156430 for an example. Note
that it's last reviewed in 2003)
In general, I prefer TCP/IP not because of any performance implication, but
for administrative convenience. For instance, names pipes depend on NetBIOS,
and require more ports through a firewall.
Linchi
"Joe K." wrote:
> I have a SQL Server 2000 Enterprise Edition database with a Windows 2000
> operating system. The Client Network Utility the protocols that are Enabled
> are TCP/IP and Named Pipes.
> TCP/IP is the first protocol in the list and second is Named Pipes.
> Could Named Pipes in the Enable protocol list slow down the database or
> connection performance?
> Thank You,
>

Monday, March 26, 2012

Named pipe error 53

I get the following error when I try to connect from an XP SP2 client to SQL
MSDE:
An error has occurred while establishing a connection to the server. When
connecting to SQL Server 2005, this failure may be caused by the fact that
under the default settings SQL Server does not allow remote connections.
(provider: Named Pipes Provider, error: 40 - Could not open a connection to
SQL Server) (Microsoft SQL Server, Error: 53)
Before last week, al worked fine, but suddenly I get this message.
What goes wrong?Is the service on another machine ? Can you reach the computer via ping ?
Did you try disabling the firewall on the Windows XP machine to see if it is
dedicted to the settings of the firewall ?
HTH, Jens K. Suessmeyer.
http://www.sqlserver2005.de
--
"Johan" <Johan@.discussions.microsoft.com> wrote in message
news:68D2C2C3-B0B1-4756-BBBD-B6A6D2577EDA@.microsoft.com...
>I get the following error when I try to connect from an XP SP2 client to
>SQL
> MSDE:
> An error has occurred while establishing a connection to the server. When
> connecting to SQL Server 2005, this failure may be caused by the fact that
> under the default settings SQL Server does not allow remote connections.
> (provider: Named Pipes Provider, error: 40 - Could not open a connection
> to
> SQL Server) (Microsoft SQL Server, Error: 53)
> Before last week, al worked fine, but suddenly I get this message.
> What goes wrong?sql

Friday, March 23, 2012

Named Instance

I couldn't connect to named instance in my client machine... I recieved the
error messange.. SQL Server Doesn't exist or Access denied. Can any one
guide me...
Thanks
See if this helps?
http://support.microsoft.com/default...265808&sd=tech
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Roy" <roy@.hotmail.com> wrote in message
news:eVq00F$hFHA.500@.TK2MSFTNGP09.phx.gbl...
>I couldn't connect to named instance in my client machine... I recieved the
> error messange.. SQL Server Doesn't exist or Access denied. Can any one
> guide me...
> Thanks
>
>
sql

Monday, March 12, 2012

mysql query then sql server 2000 query

Hi all

My client database was in mysql. Now I am converting its in sql server 2000. And all queries was written for mysql. for example this query.

This Query for MySql

CREATE TABLE `acc` (
`acc_id` int(7) NOT NULL auto_increment,
`cat_id` int(7) NOT NULL default '0',
`brand_id` int(11) NOT NULL default '0',
`item_code` varchar(100) NOT NULL default '',
`acc_name` varchar(255) NOT NULL default '',
`acc_desc` longtext NOT NULL,
`acc_spec` longtext NOT NULL,
`acc_techspec` longtext NOT NULL,
`acc_warranty` varchar(5) NOT NULL default '0',
`acc_partno` longtext NOT NULL,
`acc_serialno` longtext NOT NULL,
`acc_size` longtext NOT NULL,
`acc_weight` longtext NOT NULL,
`acc_price` int(11) NOT NULL default '0',
`acc_dprice` int(11) NOT NULL default '0',
`logos` varchar(100) NOT NULL default '',
`condition` varchar(255) NOT NULL default '',
`status` enum('available','unavailable','backorder') NOT NULL default 'available',
`approved` enum('approved','unapproved') NOT NULL default 'approved',
`addedby` varchar(10) NOT NULL default '',
`acc_date_added` varchar(50) NOT NULL default '0000-00-00',
`acc_lprice` int(11) NOT NULL default '0',
`supplier` text NOT NULL,
PRIMARY KEY (`acc_id`)
) TYPE=MyISAM;

I made it for sql srever 2000 like this

CREATE TABLE acc (
acc_id int(7) NOT NULL IDENTITY,
cat_id int(7) NOT NULL default '0',
brand_id int(11) NOT NULL default '0',
item_code varchar(100) NOT NULL default '',
acc_name varchar(255) NOT NULL default '',
acc_desc longtext NOT NULL,
acc_spec longtext NOT NULL,
acc_techspec longtext NOT NULL,
acc_warranty varchar(5) NOT NULL default '0',
acc_partno longtext NOT NULL,
acc_serialno longtext NOT NULL,
acc_size longtext NOT NULL,
acc_weight longtext NOT NULL,
acc_price int(11) NOT NULL default '0',
acc_dprice int(11) NOT NULL default '0',
logos varchar(100) NOT NULL default '',
condition varchar(255) NOT NULL default '',
--status enum('available','unavailable','backorder') NOT NULL default 'available',
status varchar(10) Not Null default 'available'
constraint chk_valid$entries$for$status
check ( status in ('available','unavailable','backorder')),
approved varchar(10) not null default 'approved'
constraint chk_valid$entries$for$approved
check ( approved in ('approved','unapproved')),
--approved enum('approved','unapproved') NOT NULL default 'approved',
addedby varchar(10) NOT NULL default '',
acc_date_added varchar(50) NOT NULL default '0000-00-00',
acc_lprice int(11) NOT NULL default '0',
supplier text NOT NULL,
PRIMARY KEY (acc_id)
) TYPE=MyISAM;

Only last line give me error. here is the error anyone could plz help me.

Server: Msg 170, Level 15, State 1, Line 32
Line 32: Incorrect syntax near '='.

Thanks

Remove this from the definition -it is unknown to SQL Server...

TYPE=MyISAM

Change the [ longtext ] datatypes to [ varchar(max) ]

Change the

enum('available','unavailable','backorder')

to a [ CHECK ]CONSTRAINT (and the other enum as well)

I think that you will probably be much happier if you were to change the [ acc_date_added ] datatype from varchar(50) to a datetime datatype with a default of [ 0 ]

Change the Supplier datatype from [ text ] to varchar(LengthAsAppropriate)

|||Here you go...

CREATE TABLE acc (
acc_id int NOT NULL IDENTITY,
cat_id int NOT NULL default '0',
brand_id int NOT NULL default '0',
item_code varchar(100) NOT NULL default '',
acc_name varchar(255) NOT NULL default '',
acc_desc text NOT NULL,
acc_spec text NOT NULL,
acc_techspec text NOT NULL,
acc_warranty varchar(5) NOT NULL default '0',
acc_partno text NOT NULL,
acc_serialno text NOT NULL,
acc_size text NOT NULL,
acc_weight text NOT NULL,
acc_price int NOT NULL default (0),
acc_dprice int NOT NULL default (0),
logos varchar(100) NOT NULL default '',
condition varchar(255) NOT NULL default '',
status varchar(10) Not Null default 'available',
approved varchar(10) not null default 'approved',
addedby varchar(10) NOT NULL default '',
acc_date_added varchar(50) NOT NULL default '0000-00-00',
acc_lprice int NOT NULL default (0),
supplier text NOT NULL,
constraint pk_acc primary key
(acc_id)
)
ALTER TABLE acc WITH CHECK ADD CONSTRAINT [CK_acc_Status]
CHECK (Status in ('available','unavailable','backorder'))
ALTER TABLE acc WITH CHECK ADD CONSTRAINT [CK_acc_approved]
CHECK (approved in ('approved','unapproved'))

Friday, March 9, 2012

mysql installation problem in Xp

hello !

I am not able to install Mysql on my pc runnig XP
..the log file shows server is readyfor connection on port 3306.

but still client not able to server .
error comes can't connect localhaost to server on port 10061

winmysqladmin showing green indiacting server is running but server
and lient info are not there.

pls help.

smita[posted and mailed]

Smita (smitap56@.rediffmail.com) writes:
> I am not able to install Mysql on my pc runnig XP
> .the log file shows server is readyfor connection on port 3306.
> but still client not able to server .
> error comes can't connect localhaost to server on port 10061
> winmysqladmin showing green indiacting server is running but server
> and lient info are not there.

Please try http://www.mysql.com. I believe they have some support forum
there. In this group we discsuss Microsoft SQL Server, so we can't help
you.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Wednesday, March 7, 2012

My XP Client doesn't access SQL Server 2000

Hi,

I have a server (WIN 2000 server), is connected with many clients mostly having Win 2000 Professional OS. My application is developed in VB 6.0 and we have MS SQL Server 2000 DB in our server. All the clients with win 2000 professional have no problem with connecting and accessing my SQL Database. But few of my WIN XP clients don’t connect to database thru my application. It gives error as follows.

Runtime error

Login Failed for user ‘(null)’ . Reason: Not associated with a trusted SQL Connection.

Can anyone help me?

Regards

Ahmed Sahib

the server needs an nt login

you are connecting with an expectation to connect to a server in mixed server mode

to do:

1. configure the system to use mixed authentication
right click the server in the enterprise manager>click on properties> security
in the authentication option choose sql server and windows
or
2. change your connection string to use an nt login

|||

What kind of login is used by your application to connect to the database? Are all your clients within the same domain?

Thanks
Laurentiu

|||

Thanks Mr.Joe for your promp reply. My Server has mixed authentication.

I can ping; browse the server from my XP client. So there is no trouble in my network connection settings.

|||

Thanks Mr. Laurentiu Cristofor

Yes, My All clients are in the same domain. Kindly read my previous post.

Thanks

Ahmed Sahib

|||

Are your clients in the same domain as the server? Are you sure that they are attempting to connect using SQL Authentication and not using Windows authentication?

Thanks
Laurentiu

my Synchronization Scenario

Hi, I want to know the a solution for my Synchronization Scenario

I have a several client databses which are SQL Server 2005 Express and i have a master database which is SQL Server 2000 containing all the individual Client databases. All the individual client databases are kept seperately at the master location. I need to Synchronization the client database with its copy at the master database (something like Merge replication). Both the Client Copy as well as Master Copy could be Publishers & Subscribers.

Now the problem is Because of security & firewall issues, only the Client should have the ability to schedule & initiate the synchronization process with the master copy. Unfortunately SQL Server 2005 Express has only subscriber agent and not a publisher agent.

Any help on how to achieve this would be appreciated . Thank Youno idea, but you implimented BETA technology. Any chance you can get everything on MSDE?

Friday, March 30, 2012

named set questions

Named Pipes vs TCP/IP

Named Pipes vs TCP/IP

Named Pipes vs TCP

named pipes under alias

Wednesday, March 28, 2012

Named Pipes

Named Pipes

Named Pipes

Monday, March 26, 2012

Named pipe error 53

Friday, March 23, 2012

Named Instance

Monday, March 12, 2012

mysql query then sql server 2000 query

Friday, March 9, 2012

mysql installation problem in Xp

Wednesday, March 7, 2012

My XP Client doesn't access SQL Server 2000

my Synchronization Scenario

MDF Files currupted

Blog Archive

About Me