Dear all,
I'm a noob to SQL Reporting Services but have plenty of experience with
other MS applications (including excel and access). I was wondering whether
it's possible to combine a cross-tab and a chart within a single report. If
so, how do you do this? I believe the power of a report (often) exists out of
numbers combined with a graphical display.
thanks in advance,
mischaOn Apr 26, 10:22 am, mischa <mis...@.discussions.microsoft.com> wrote:
> Dear all,
> I'm a noob to SQL Reporting Services but have plenty of experience with
> other MS applications (including excel and access). I was wondering whether
> it's possible to combine a cross-tab and a chart within a single report. If
> so, how do you do this? I believe the power of a report (often) exists out of
> numbers combined with a graphical display.
> thanks in advance,
> mischa
If I understand you correctly, you should be able to use a matrix
control and a chart control.
Regards,
Enrique Martinez
Sr. Software Consultant
Showing posts with label applications. Show all posts
Showing posts with label applications. Show all posts
Sunday, March 25, 2012
Monday, March 19, 2012
Combine aspnetdb with the applications database
I have tried to find all the threads related to this topic. At this point I would like to find out what the best practices are for doing this.
I plan to use Membership, Roles, and the login controls to handle my authentication and permissions issues. I want to use the same database for my application data as for Application Services, using a standard SQL Server.
So far, the easiest way to set this up that I can think of is to:
1. Use aspnet_regsql.exe to create the Application Services Database schema
2. Edit the "LocalSqlServer" entry in <connectionStrings> to point to the above database
3. Add the tables, views, stored procedures, etc., that I need for my application into the database created in step 1
Is there any more configuration I need to do to get Membership and Roles working? When I did the Walkthrough, step 2 seemed to be the only requirement for getting Membership and Roles to work.
Will I run into any trouble using LocalSqlServer for my application data updates?
I would be interested in any other approaches to setting up a combined database, including opinions why and why not to do it.
There should be no other problem if you've configrue the application to connect to the right database using login which has proper permissions on that database. You cna take a look at Scott's article if you haven't read it yet:
http://weblogs.asp.net/scottgu/archive/2005/08/25/423703.aspx
Sunday, March 11, 2012
COM+ Applications hanging
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
This is very typical of a buggy COM+ DLL which fails to return for whatever
reason.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
There are a gazillion reasons. There is simply insufficient information
provided to hazard a guess what is responsible in your case.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
Having gone down this road several times myself, I've simply used standard
debugging strategies. In my design, I have built-in tracing designed as part
of the COM+ DLL's that can be turned on or off by a simply registry setting.
This produces log messages stored in a log file for analysis in case these
situations arises. This can provide a lot of insight as to what is
happening.
I really can't be more specific given the limited amount of information you
have posted, but hopefully this will keep you from going off on a tangent
and blaming the COM+ infrastructure, when it fact it is really solid (at
least in my experience).
Brian
|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:#Updhbn1FHA.904@.tk2msftngp13.phx.gbl...[vbcol=seagreen]
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of[vbcol=seagreen]
clears
> This is very typical of a buggy COM+ DLL which fails to return for
whatever[vbcol=seagreen]
> reason.
a[vbcol=seagreen]
> There are a gazillion reasons. There is simply insufficient information
> provided to hazard a guess what is responsible in your case.
show
> Having gone down this road several times myself, I've simply used standard
> debugging strategies. In my design, I have built-in tracing designed as
part
> of the COM+ DLL's that can be turned on or off by a simply registry
setting.
> This produces log messages stored in a log file for analysis in case these
> situations arises. This can provide a lot of insight as to what is
> happening.
> I really can't be more specific given the limited amount of information
you
> have posted, but hopefully this will keep you from going off on a tangent
> and blaming the COM+ infrastructure, when it fact it is really solid (at
> least in my experience).
> Brian
>
Thanks for the response Brian. I am not necessarily blaming the COM+
infrastructure. Just trying to make sense of this. We have recently put
in a bunch of code to try to handle all error conditions and exceptions and
are logging them. So far nothing shows up in our logs except a sesation of
logging anything until the application is shutdown and restarted.
We have two different dlls written by different people. The commonality is
they use ADO to talk to SQL Server 2000. I can't reproduce the error in
our test environment and it doesn't happen on all of our systems and is
sporadic but very annoying.
I think what I need are tools so that when it happens I can figure out where
it's occuring and why. I also need to understand the subsystem better.
What would cause the whole application to hang if only one instance of the
component had issues? Could there be a problem with SQL Connections?
The database typically looks fine when this occurs so I don't think it's a
db call that is hanging in SQL.
|||>
> What would cause the whole application to hang if only one instance of the
> component had issues?
You mean you want an example? Ok, if the COM+ object requires a transaction,
then all it takes is for one object to fail or hang, and all subsequent
calls are blocked.
Could there be a problem with SQL Connections?
What sort of problem are you thinking of?
Brian
|||attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д? news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric
|||John, thanks for the response. I probably will be calling MS. I'm not
sure how to attach a debugger in this production environment. Are you
referring to a stand-alone debugging tool that'll work outside of the
development environment.
"John" <lanxiaowei@.hotmail.com> wrote in message
news:OdXBhw#1FHA.2008@.TK2MSFTNGP10.phx.gbl...
attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д?
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB
Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric
|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:O2bKUOp1FHA.1032@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
the
> You mean you want an example? Ok, if the COM+ object requires a
transaction,
> then all it takes is for one object to fail or hang, and all subsequent
> calls are blocked.
>
But that would only be from the same client, correct? If a different
client with a different handle to the interface makes a call shouldn't it
have it's own process flow?
> Could there be a problem with SQL Connections?
> What sort of problem are you thinking of?
>
Just wondering if there could be some sort of blocking or threading issue
that would cause all SQL connections (since there is pooling going on) to be
blocked so any calls made to the components would "hang" because they are
primarliy doing db calls via ADO.
|||Response inline...
Michael D. Long
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
When operating against the DBMS at Read Serializable isolation, a long
running transaction that acquires an exclusive lock on a single data row
will block all other connections accessing the same data row. For that
reason, when developing COM+ applications the developer needs to be
intimately familiar with database locking behavior and data usage patterns.
I saw one guy try to avoid a scalability issue by creating a connection
outside of the scope of the distributed transaction in an effort to improve
performance on a system designed by another team that was bottlenecked at 8
concurrent users. This approach managed to "intermittently" deadlock the
entire application, because the non-transactional connection was contending
with the connection enlisted in the distributed transaction for the same
data row - and his internal recovery logic kept retrying until the object
was terminated.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
If this is a data related bottleneck you can run a trace of the activity. A
thorough design review wouldn't hurt - this should include validation of the
data access patterns as well as line by line source code walk through.
|||> When operating against the DBMS at Read Serializable isolation, a long
> running transaction that acquires an exclusive lock on a single data row
> will block all other connections accessing the same data row. For that
> reason, when developing COM+ applications the developer needs to be
> intimately familiar with database locking behavior and data usage
patterns.
> I saw one guy try to avoid a scalability issue by creating a connection
> outside of the scope of the distributed transaction in an effort to
improve
> performance on a system designed by another team that was bottlenecked at
8
> concurrent users. This approach managed to "intermittently" deadlock the
> entire application, because the non-transactional connection was
contending
> with the connection enlisted in the distributed transaction for the same
> data row - and his internal recovery logic kept retrying until the object
> was terminated.
Michael would this be detectable from looking at the SQL Server database or
could it appear quiet on the db end with the problem lying wihtin the ADO
calls in the component? I ask because I know that SQL server isn't locking
according to our database team when this happens.
[vbcol=seagreen]
show
> If this is a data related bottleneck you can run a trace of the activity.
A
> thorough design review wouldn't hurt - this should include validation of
the
> data access patterns as well as line by line source code walk through.
>
Thanks for the suggestions.
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
This is very typical of a buggy COM+ DLL which fails to return for whatever
reason.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
There are a gazillion reasons. There is simply insufficient information
provided to hazard a guess what is responsible in your case.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
Having gone down this road several times myself, I've simply used standard
debugging strategies. In my design, I have built-in tracing designed as part
of the COM+ DLL's that can be turned on or off by a simply registry setting.
This produces log messages stored in a log file for analysis in case these
situations arises. This can provide a lot of insight as to what is
happening.
I really can't be more specific given the limited amount of information you
have posted, but hopefully this will keep you from going off on a tangent
and blaming the COM+ infrastructure, when it fact it is really solid (at
least in my experience).
Brian
|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:#Updhbn1FHA.904@.tk2msftngp13.phx.gbl...[vbcol=seagreen]
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of[vbcol=seagreen]
clears
> This is very typical of a buggy COM+ DLL which fails to return for
whatever[vbcol=seagreen]
> reason.
a[vbcol=seagreen]
> There are a gazillion reasons. There is simply insufficient information
> provided to hazard a guess what is responsible in your case.
show
> Having gone down this road several times myself, I've simply used standard
> debugging strategies. In my design, I have built-in tracing designed as
part
> of the COM+ DLL's that can be turned on or off by a simply registry
setting.
> This produces log messages stored in a log file for analysis in case these
> situations arises. This can provide a lot of insight as to what is
> happening.
> I really can't be more specific given the limited amount of information
you
> have posted, but hopefully this will keep you from going off on a tangent
> and blaming the COM+ infrastructure, when it fact it is really solid (at
> least in my experience).
> Brian
>
Thanks for the response Brian. I am not necessarily blaming the COM+
infrastructure. Just trying to make sense of this. We have recently put
in a bunch of code to try to handle all error conditions and exceptions and
are logging them. So far nothing shows up in our logs except a sesation of
logging anything until the application is shutdown and restarted.
We have two different dlls written by different people. The commonality is
they use ADO to talk to SQL Server 2000. I can't reproduce the error in
our test environment and it doesn't happen on all of our systems and is
sporadic but very annoying.
I think what I need are tools so that when it happens I can figure out where
it's occuring and why. I also need to understand the subsystem better.
What would cause the whole application to hang if only one instance of the
component had issues? Could there be a problem with SQL Connections?
The database typically looks fine when this occurs so I don't think it's a
db call that is hanging in SQL.
|||>
> What would cause the whole application to hang if only one instance of the
> component had issues?
You mean you want an example? Ok, if the COM+ object requires a transaction,
then all it takes is for one object to fail or hang, and all subsequent
calls are blocked.
Could there be a problem with SQL Connections?
What sort of problem are you thinking of?
Brian
|||attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д? news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric
|||John, thanks for the response. I probably will be calling MS. I'm not
sure how to attach a debugger in this production environment. Are you
referring to a stand-alone debugging tool that'll work outside of the
development environment.
"John" <lanxiaowei@.hotmail.com> wrote in message
news:OdXBhw#1FHA.2008@.TK2MSFTNGP10.phx.gbl...
attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д?
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB
Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric
|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:O2bKUOp1FHA.1032@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
the
> You mean you want an example? Ok, if the COM+ object requires a
transaction,
> then all it takes is for one object to fail or hang, and all subsequent
> calls are blocked.
>
But that would only be from the same client, correct? If a different
client with a different handle to the interface makes a call shouldn't it
have it's own process flow?
> Could there be a problem with SQL Connections?
> What sort of problem are you thinking of?
>
Just wondering if there could be some sort of blocking or threading issue
that would cause all SQL connections (since there is pooling going on) to be
blocked so any calls made to the components would "hang" because they are
primarliy doing db calls via ADO.
|||Response inline...
Michael D. Long
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
When operating against the DBMS at Read Serializable isolation, a long
running transaction that acquires an exclusive lock on a single data row
will block all other connections accessing the same data row. For that
reason, when developing COM+ applications the developer needs to be
intimately familiar with database locking behavior and data usage patterns.
I saw one guy try to avoid a scalability issue by creating a connection
outside of the scope of the distributed transaction in an effort to improve
performance on a system designed by another team that was bottlenecked at 8
concurrent users. This approach managed to "intermittently" deadlock the
entire application, because the non-transactional connection was contending
with the connection enlisted in the distributed transaction for the same
data row - and his internal recovery logic kept retrying until the object
was terminated.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
If this is a data related bottleneck you can run a trace of the activity. A
thorough design review wouldn't hurt - this should include validation of the
data access patterns as well as line by line source code walk through.
|||> When operating against the DBMS at Read Serializable isolation, a long
> running transaction that acquires an exclusive lock on a single data row
> will block all other connections accessing the same data row. For that
> reason, when developing COM+ applications the developer needs to be
> intimately familiar with database locking behavior and data usage
patterns.
> I saw one guy try to avoid a scalability issue by creating a connection
> outside of the scope of the distributed transaction in an effort to
improve
> performance on a system designed by another team that was bottlenecked at
8
> concurrent users. This approach managed to "intermittently" deadlock the
> entire application, because the non-transactional connection was
contending
> with the connection enlisted in the distributed transaction for the same
> data row - and his internal recovery logic kept retrying until the object
> was terminated.
Michael would this be detectable from looking at the SQL Server database or
could it appear quiet on the db end with the problem lying wihtin the ADO
calls in the component? I ask because I know that SQL server isn't locking
according to our database team when this happens.
[vbcol=seagreen]
show
> If this is a data related bottleneck you can run a trace of the activity.
A
> thorough design review wouldn't hurt - this should include validation of
the
> data access patterns as well as line by line source code walk through.
>
Thanks for the suggestions.
COM+ Applications hanging
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
This is very typical of a buggy COM+ DLL which fails to return for whatever
reason.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
There are a gazillion reasons. There is simply insufficient information
provided to hazard a guess what is responsible in your case.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
Having gone down this road several times myself, I've simply used standard
debugging strategies. In my design, I have built-in tracing designed as part
of the COM+ DLL's that can be turned on or off by a simply registry setting.
This produces log messages stored in a log file for analysis in case these
situations arises. This can provide a lot of insight as to what is
happening.
I really can't be more specific given the limited amount of information you
have posted, but hopefully this will keep you from going off on a tangent
and blaming the COM+ infrastructure, when it fact it is really solid (at
least in my experience).
Brian|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:#Updhbn1FHA.904@.tk2msftngp13.phx.gbl...
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of[vbcol=seagreen]
clears[vbcol=seagreen]
> This is very typical of a buggy COM+ DLL which fails to return for
whatever
> reason.
>
a[vbcol=seagreen]
> There are a gazillion reasons. There is simply insufficient information
> provided to hazard a guess what is responsible in your case.
>
show[vbcol=seagreen]
> Having gone down this road several times myself, I've simply used standard
> debugging strategies. In my design, I have built-in tracing designed as
part
> of the COM+ DLL's that can be turned on or off by a simply registry
setting.
> This produces log messages stored in a log file for analysis in case these
> situations arises. This can provide a lot of insight as to what is
> happening.
> I really can't be more specific given the limited amount of information
you
> have posted, but hopefully this will keep you from going off on a tangent
> and blaming the COM+ infrastructure, when it fact it is really solid (at
> least in my experience).
> Brian
>
Thanks for the response Brian. I am not necessarily blaming the COM+
infrastructure. Just trying to make sense of this. We have recently put
in a bunch of code to try to handle all error conditions and exceptions and
are logging them. So far nothing shows up in our logs except a sesation of
logging anything until the application is shutdown and restarted.
We have two different dlls written by different people. The commonality is
they use ADO to talk to SQL Server 2000. I can't reproduce the error in
our test environment and it doesn't happen on all of our systems and is
sporadic but very annoying.
I think what I need are tools so that when it happens I can figure out where
it's occuring and why. I also need to understand the subsystem better.
What would cause the whole application to hang if only one instance of the
component had issues? Could there be a problem with SQL Connections?
The database typically looks fine when this occurs so I don't think it's a
db call that is hanging in SQL.|||>
> What would cause the whole application to hang if only one instance of the
> component had issues?
You mean you want an example? Ok, if the COM+ object requires a transaction,
then all it takes is for one object to fail or hang, and all subsequent
calls are blocked.
Could there be a problem with SQL Connections?
What sort of problem are you thinking of?
Brian|||attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д? news:u%23op5
2m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||John, thanks for the response. I probably will be calling MS. I'm not
sure how to attach a debugger in this production environment. Are you
referring to a stand-alone debugging tool that'll work outside of the
development environment.
"John" <lanxiaowei@.hotmail.com> wrote in message
news:OdXBhw#1FHA.2008@.TK2MSFTNGP10.phx.gbl...
attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д?
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB
Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:O2bKUOp1FHA.1032@.TK2MSFTNGP12.phx.gbl...
the[vbcol=seagreen]
> You mean you want an example? Ok, if the COM+ object requires a
transaction,
> then all it takes is for one object to fail or hang, and all subsequent
> calls are blocked.
>
But that would only be from the same client, correct? If a different
client with a different handle to the interface makes a call shouldn't it
have it's own process flow?
> Could there be a problem with SQL Connections?
> What sort of problem are you thinking of?
>
Just wondering if there could be some sort of blocking or threading issue
that would cause all SQL connections (since there is pooling going on) to be
blocked so any calls made to the components would "hang" because they are
primarliy doing db calls via ADO.|||Response inline...
Michael D. Long
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
When operating against the DBMS at Read Serializable isolation, a long
running transaction that acquires an exclusive lock on a single data row
will block all other connections accessing the same data row. For that
reason, when developing COM+ applications the developer needs to be
intimately familiar with database locking behavior and data usage patterns.
I saw one guy try to avoid a scalability issue by creating a connection
outside of the scope of the distributed transaction in an effort to improve
performance on a system designed by another team that was bottlenecked at 8
concurrent users. This approach managed to "intermittently" deadlock the
entire application, because the non-transactional connection was contending
with the connection enlisted in the distributed transaction for the same
data row - and his internal recovery logic kept retrying until the object
was terminated.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
If this is a data related bottleneck you can run a trace of the activity. A
thorough design review wouldn't hurt - this should include validation of the
data access patterns as well as line by line source code walk through.|||> When operating against the DBMS at Read Serializable isolation, a long
> running transaction that acquires an exclusive lock on a single data row
> will block all other connections accessing the same data row. For that
> reason, when developing COM+ applications the developer needs to be
> intimately familiar with database locking behavior and data usage
patterns.
> I saw one guy try to avoid a scalability issue by creating a connection
> outside of the scope of the distributed transaction in an effort to
improve
> performance on a system designed by another team that was bottlenecked at
8
> concurrent users. This approach managed to "intermittently" deadlock the
> entire application, because the non-transactional connection was
contending
> with the connection enlisted in the distributed transaction for the same
> data row - and his internal recovery logic kept retrying until the object
> was terminated.
Michael would this be detectable from looking at the SQL Server database or
could it appear quiet on the db end with the problem lying wihtin the ADO
calls in the component? I ask because I know that SQL server isn't locking
according to our database team when this happens.
show[vbcol=seagreen]
> If this is a data related bottleneck you can run a trace of the activity.
A
> thorough design review wouldn't hurt - this should include validation of
the
> data access patterns as well as line by line source code walk through.
>
Thanks for the suggestions.
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
This is very typical of a buggy COM+ DLL which fails to return for whatever
reason.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
There are a gazillion reasons. There is simply insufficient information
provided to hazard a guess what is responsible in your case.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
Having gone down this road several times myself, I've simply used standard
debugging strategies. In my design, I have built-in tracing designed as part
of the COM+ DLL's that can be turned on or off by a simply registry setting.
This produces log messages stored in a log file for analysis in case these
situations arises. This can provide a lot of insight as to what is
happening.
I really can't be more specific given the limited amount of information you
have posted, but hopefully this will keep you from going off on a tangent
and blaming the COM+ infrastructure, when it fact it is really solid (at
least in my experience).
Brian|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:#Updhbn1FHA.904@.tk2msftngp13.phx.gbl...
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of[vbcol=seagreen]
clears[vbcol=seagreen]
> This is very typical of a buggy COM+ DLL which fails to return for
whatever
> reason.
>
a[vbcol=seagreen]
> There are a gazillion reasons. There is simply insufficient information
> provided to hazard a guess what is responsible in your case.
>
show[vbcol=seagreen]
> Having gone down this road several times myself, I've simply used standard
> debugging strategies. In my design, I have built-in tracing designed as
part
> of the COM+ DLL's that can be turned on or off by a simply registry
setting.
> This produces log messages stored in a log file for analysis in case these
> situations arises. This can provide a lot of insight as to what is
> happening.
> I really can't be more specific given the limited amount of information
you
> have posted, but hopefully this will keep you from going off on a tangent
> and blaming the COM+ infrastructure, when it fact it is really solid (at
> least in my experience).
> Brian
>
Thanks for the response Brian. I am not necessarily blaming the COM+
infrastructure. Just trying to make sense of this. We have recently put
in a bunch of code to try to handle all error conditions and exceptions and
are logging them. So far nothing shows up in our logs except a sesation of
logging anything until the application is shutdown and restarted.
We have two different dlls written by different people. The commonality is
they use ADO to talk to SQL Server 2000. I can't reproduce the error in
our test environment and it doesn't happen on all of our systems and is
sporadic but very annoying.
I think what I need are tools so that when it happens I can figure out where
it's occuring and why. I also need to understand the subsystem better.
What would cause the whole application to hang if only one instance of the
component had issues? Could there be a problem with SQL Connections?
The database typically looks fine when this occurs so I don't think it's a
db call that is hanging in SQL.|||>
> What would cause the whole application to hang if only one instance of the
> component had issues?
You mean you want an example? Ok, if the COM+ object requires a transaction,
then all it takes is for one object to fail or hang, and all subsequent
calls are blocked.
Could there be a problem with SQL Connections?
What sort of problem are you thinking of?
Brian|||attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д? news:u%23op5
2m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||John, thanks for the response. I probably will be calling MS. I'm not
sure how to attach a debugger in this production environment. Are you
referring to a stand-alone debugging tool that'll work outside of the
development environment.
"John" <lanxiaowei@.hotmail.com> wrote in message
news:OdXBhw#1FHA.2008@.TK2MSFTNGP10.phx.gbl...
attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д?
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB
Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:O2bKUOp1FHA.1032@.TK2MSFTNGP12.phx.gbl...
the[vbcol=seagreen]
> You mean you want an example? Ok, if the COM+ object requires a
transaction,
> then all it takes is for one object to fail or hang, and all subsequent
> calls are blocked.
>
But that would only be from the same client, correct? If a different
client with a different handle to the interface makes a call shouldn't it
have it's own process flow?
> Could there be a problem with SQL Connections?
> What sort of problem are you thinking of?
>
Just wondering if there could be some sort of blocking or threading issue
that would cause all SQL connections (since there is pooling going on) to be
blocked so any calls made to the components would "hang" because they are
primarliy doing db calls via ADO.|||Response inline...
Michael D. Long
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
When operating against the DBMS at Read Serializable isolation, a long
running transaction that acquires an exclusive lock on a single data row
will block all other connections accessing the same data row. For that
reason, when developing COM+ applications the developer needs to be
intimately familiar with database locking behavior and data usage patterns.
I saw one guy try to avoid a scalability issue by creating a connection
outside of the scope of the distributed transaction in an effort to improve
performance on a system designed by another team that was bottlenecked at 8
concurrent users. This approach managed to "intermittently" deadlock the
entire application, because the non-transactional connection was contending
with the connection enlisted in the distributed transaction for the same
data row - and his internal recovery logic kept retrying until the object
was terminated.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
If this is a data related bottleneck you can run a trace of the activity. A
thorough design review wouldn't hurt - this should include validation of the
data access patterns as well as line by line source code walk through.|||> When operating against the DBMS at Read Serializable isolation, a long
> running transaction that acquires an exclusive lock on a single data row
> will block all other connections accessing the same data row. For that
> reason, when developing COM+ applications the developer needs to be
> intimately familiar with database locking behavior and data usage
patterns.
> I saw one guy try to avoid a scalability issue by creating a connection
> outside of the scope of the distributed transaction in an effort to
improve
> performance on a system designed by another team that was bottlenecked at
8
> concurrent users. This approach managed to "intermittently" deadlock the
> entire application, because the non-transactional connection was
contending
> with the connection enlisted in the distributed transaction for the same
> data row - and his internal recovery logic kept retrying until the object
> was terminated.
Michael would this be detectable from looking at the SQL Server database or
could it appear quiet on the db end with the problem lying wihtin the ADO
calls in the component? I ask because I know that SQL server isn't locking
according to our database team when this happens.
show[vbcol=seagreen]
> If this is a data related bottleneck you can run a trace of the activity.
A
> thorough design review wouldn't hurt - this should include validation of
the
> data access patterns as well as line by line source code walk through.
>
Thanks for the suggestions.
COM+ Applications hanging
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
This is very typical of a buggy COM+ DLL which fails to return for whatever
reason.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
There are a gazillion reasons. There is simply insufficient information
provided to hazard a guess what is responsible in your case.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
Having gone down this road several times myself, I've simply used standard
debugging strategies. In my design, I have built-in tracing designed as part
of the COM+ DLL's that can be turned on or off by a simply registry setting.
This produces log messages stored in a log file for analysis in case these
situations arises. This can provide a lot of insight as to what is
happening.
I really can't be more specific given the limited amount of information you
have posted, but hopefully this will keep you from going off on a tangent
and blaming the COM+ infrastructure, when it fact it is really solid (at
least in my experience).
Brian|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:#Updhbn1FHA.904@.tk2msftngp13.phx.gbl...
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of
clears
> This is very typical of a buggy COM+ DLL which fails to return for
whatever
> reason.
>
a
> There are a gazillion reasons. There is simply insufficient information
> provided to hazard a guess what is responsible in your case.
>
show
> Having gone down this road several times myself, I've simply used standard
> debugging strategies. In my design, I have built-in tracing designed as
part
> of the COM+ DLL's that can be turned on or off by a simply registry
setting.
> This produces log messages stored in a log file for analysis in case these
> situations arises. This can provide a lot of insight as to what is
> happening.
> I really can't be more specific given the limited amount of information
you
> have posted, but hopefully this will keep you from going off on a tangent
> and blaming the COM+ infrastructure, when it fact it is really solid (at
> least in my experience).
> Brian
>
Thanks for the response Brian. I am not necessarily blaming the COM+
infrastructure. Just trying to make sense of this. We have recently put
in a bunch of code to try to handle all error conditions and exceptions and
are logging them. So far nothing shows up in our logs except a sesation of
logging anything until the application is shutdown and restarted.
We have two different dlls written by different people. The commonality is
they use ADO to talk to SQL Server 2000. I can't reproduce the error in
our test environment and it doesn't happen on all of our systems and is
sporadic but very annoying.
I think what I need are tools so that when it happens I can figure out where
it's occuring and why. I also need to understand the subsystem better.
What would cause the whole application to hang if only one instance of the
component had issues? Could there be a problem with SQL Connections?
The database typically looks fine when this occurs so I don't think it's a
db call that is hanging in SQL.|||>
> What would cause the whole application to hang if only one instance of the
> component had issues?
You mean you want an example? Ok, if the COM+ object requires a transaction,
then all it takes is for one object to fail or hang, and all subsequent
calls are blocked.
Could there be a problem with SQL Connections?
What sort of problem are you thinking of?
Brian|||attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д? news:u%23op5
2m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||John, thanks for the response. I probably will be calling MS. I'm not
sure how to attach a debugger in this production environment. Are you
referring to a stand-alone debugging tool that'll work outside of the
development environment.
"John" <lanxiaowei@.hotmail.com> wrote in message
news:OdXBhw#1FHA.2008@.TK2MSFTNGP10.phx.gbl...
attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д?
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB
Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:O2bKUOp1FHA.1032@.TK2MSFTNGP12.phx.gbl...
the
> You mean you want an example? Ok, if the COM+ object requires a
transaction,
> then all it takes is for one object to fail or hang, and all subsequent
> calls are blocked.
>
But that would only be from the same client, correct? If a different
client with a different handle to the interface makes a call shouldn't it
have it's own process flow?
> Could there be a problem with SQL Connections?
> What sort of problem are you thinking of?
>
Just wondering if there could be some sort of blocking or threading issue
that would cause all SQL connections (since there is pooling going on) to be
blocked so any calls made to the components would "hang" because they are
primarliy doing db calls via ADO.|||"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
> Any help would be greatly appreciated. This is driving me nuts as it's
> like finding a needle in a haystack.
Have you considered the possibility of a SQL deadlock? Execute sp_who2 when
the condition occurs again, to see if your [SQL] process is being blocked by
another. If that is the case, you can use Enterprise Manager
(Management->Current Activity->Process Info) to investigate further. From
there, by double-clicking a process item, you can [usually] view the last
SQL statement executed. From there you may or may not have your work cut
out for you, depending on the circumstances, of course.
-Mark
[non-relevant cross-posts removed]
> Thanks
> Eric
>|||Response inline...
Michael D. Long
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
When operating against the DBMS at Read Serializable isolation, a long
running transaction that acquires an exclusive lock on a single data row
will block all other connections accessing the same data row. For that
reason, when developing COM+ applications the developer needs to be
intimately familiar with database locking behavior and data usage patterns.
I saw one guy try to avoid a scalability issue by creating a connection
outside of the scope of the distributed transaction in an effort to improve
performance on a system designed by another team that was bottlenecked at 8
concurrent users. This approach managed to "intermittently" deadlock the
entire application, because the non-transactional connection was contending
with the connection enlisted in the distributed transaction for the same
data row - and his internal recovery logic kept retrying until the object
was terminated.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
If this is a data related bottleneck you can run a trace of the activity. A
thorough design review wouldn't hurt - this should include validation of the
data access patterns as well as line by line source code walk through.|||"Mark J. McGinty" <mmcginty@.spamfromyou.com> wrote in message
news:#InvFiS2FHA.3244@.tk2msftngp13.phx.gbl...
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of
clears
a
show
> Have you considered the possibility of a SQL deadlock? Execute sp_who2
when
> the condition occurs again, to see if your [SQL] process is being blocked
by
> another. If that is the case, you can use Enterprise Manager
> (Management->Current Activity->Process Info) to investigate further. From
> there, by double-clicking a process item, you can [usually] view the last
> SQL statement executed. From there you may or may not have your work cut
> out for you, depending on the circumstances, of course.
>
Thanks Mark. Yes I have considered that. Whenever this occurs I have the
db team look at SQL. Sometimes our problem is with database load/locking
but in the cases I'm trying to debug the database is quiet.
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
This is very typical of a buggy COM+ DLL which fails to return for whatever
reason.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
There are a gazillion reasons. There is simply insufficient information
provided to hazard a guess what is responsible in your case.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
Having gone down this road several times myself, I've simply used standard
debugging strategies. In my design, I have built-in tracing designed as part
of the COM+ DLL's that can be turned on or off by a simply registry setting.
This produces log messages stored in a log file for analysis in case these
situations arises. This can provide a lot of insight as to what is
happening.
I really can't be more specific given the limited amount of information you
have posted, but hopefully this will keep you from going off on a tangent
and blaming the COM+ infrastructure, when it fact it is really solid (at
least in my experience).
Brian|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:#Updhbn1FHA.904@.tk2msftngp13.phx.gbl...
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of
clears
> This is very typical of a buggy COM+ DLL which fails to return for
whatever
> reason.
>
a
> There are a gazillion reasons. There is simply insufficient information
> provided to hazard a guess what is responsible in your case.
>
show
> Having gone down this road several times myself, I've simply used standard
> debugging strategies. In my design, I have built-in tracing designed as
part
> of the COM+ DLL's that can be turned on or off by a simply registry
setting.
> This produces log messages stored in a log file for analysis in case these
> situations arises. This can provide a lot of insight as to what is
> happening.
> I really can't be more specific given the limited amount of information
you
> have posted, but hopefully this will keep you from going off on a tangent
> and blaming the COM+ infrastructure, when it fact it is really solid (at
> least in my experience).
> Brian
>
Thanks for the response Brian. I am not necessarily blaming the COM+
infrastructure. Just trying to make sense of this. We have recently put
in a bunch of code to try to handle all error conditions and exceptions and
are logging them. So far nothing shows up in our logs except a sesation of
logging anything until the application is shutdown and restarted.
We have two different dlls written by different people. The commonality is
they use ADO to talk to SQL Server 2000. I can't reproduce the error in
our test environment and it doesn't happen on all of our systems and is
sporadic but very annoying.
I think what I need are tools so that when it happens I can figure out where
it's occuring and why. I also need to understand the subsystem better.
What would cause the whole application to hang if only one instance of the
component had issues? Could there be a problem with SQL Connections?
The database typically looks fine when this occurs so I don't think it's a
db call that is hanging in SQL.|||>
> What would cause the whole application to hang if only one instance of the
> component had issues?
You mean you want an example? Ok, if the COM+ object requires a transaction,
then all it takes is for one object to fail or hang, and all subsequent
calls are blocked.
Could there be a problem with SQL Connections?
What sort of problem are you thinking of?
Brian|||attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д? news:u%23op5
2m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||John, thanks for the response. I probably will be calling MS. I'm not
sure how to attach a debugger in this production environment. Are you
referring to a stand-alone debugging tool that'll work outside of the
development environment.
"John" <lanxiaowei@.hotmail.com> wrote in message
news:OdXBhw#1FHA.2008@.TK2MSFTNGP10.phx.gbl...
attach a debugger to the hang process and check all thread call
stack should be a fast way to check which thread makes a blocking call.
if this issue has a considerable business impact, i suggest you
submit a service request to Microsoft PSS to ask them for assistance.
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> д?
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
I have two ATL Dlls that have multiple interfaces and run under two COM+
Applications. Each DLL accesses SQL Server db via ADO calls and one of
the components also interacts with a 3rd party report server system.
We run into intermittent issues with the COM+ Application hanging. Our
client application will go into the tank and checking Component Services
will show that the max call time is very high and just keeps climbing.
Recycling the COM+ Application will typically fix the problem as it clears
out all memory, connections etc.
I'm struggling to figure out if our components have a bug in them or if
there is something flakey about COM+ Applications and perhaps DB
Connection
Pooling.
What would cause one instance to hang and then block all other calls to a
COM+ Application?
Are there any good tools that can hack inside the low-level calls and show
what's causing the bottleneck?
Any help would be greatly appreciated. This is driving me nuts as it's
like finding a needle in a haystack.
Thanks
Eric|||"Brian Muth" <bmuth@.mvps.org> wrote in message
news:O2bKUOp1FHA.1032@.TK2MSFTNGP12.phx.gbl...
the
> You mean you want an example? Ok, if the COM+ object requires a
transaction,
> then all it takes is for one object to fail or hang, and all subsequent
> calls are blocked.
>
But that would only be from the same client, correct? If a different
client with a different handle to the interface makes a call shouldn't it
have it's own process flow?
> Could there be a problem with SQL Connections?
> What sort of problem are you thinking of?
>
Just wondering if there could be some sort of blocking or threading issue
that would cause all SQL connections (since there is pooling going on) to be
blocked so any calls made to the components would "hang" because they are
primarliy doing db calls via ADO.|||"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
>I have two ATL Dlls that have multiple interfaces and run under two COM+
> Applications. Each DLL accesses SQL Server db via ADO calls and one of
> the components also interacts with a 3rd party report server system.
> We run into intermittent issues with the COM+ Application hanging. Our
> client application will go into the tank and checking Component Services
> will show that the max call time is very high and just keeps climbing.
> Recycling the COM+ Application will typically fix the problem as it clears
> out all memory, connections etc.
> I'm struggling to figure out if our components have a bug in them or if
> there is something flakey about COM+ Applications and perhaps DB
> Connection
> Pooling.
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
> Any help would be greatly appreciated. This is driving me nuts as it's
> like finding a needle in a haystack.
Have you considered the possibility of a SQL deadlock? Execute sp_who2 when
the condition occurs again, to see if your [SQL] process is being blocked by
another. If that is the case, you can use Enterprise Manager
(Management->Current Activity->Process Info) to investigate further. From
there, by double-clicking a process item, you can [usually] view the last
SQL statement executed. From there you may or may not have your work cut
out for you, depending on the circumstances, of course.
-Mark
[non-relevant cross-posts removed]
> Thanks
> Eric
>|||Response inline...
Michael D. Long
"Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
> What would cause one instance to hang and then block all other calls to a
> COM+ Application?
>
When operating against the DBMS at Read Serializable isolation, a long
running transaction that acquires an exclusive lock on a single data row
will block all other connections accessing the same data row. For that
reason, when developing COM+ applications the developer needs to be
intimately familiar with database locking behavior and data usage patterns.
I saw one guy try to avoid a scalability issue by creating a connection
outside of the scope of the distributed transaction in an effort to improve
performance on a system designed by another team that was bottlenecked at 8
concurrent users. This approach managed to "intermittently" deadlock the
entire application, because the non-transactional connection was contending
with the connection enlisted in the distributed transaction for the same
data row - and his internal recovery logic kept retrying until the object
was terminated.
> Are there any good tools that can hack inside the low-level calls and show
> what's causing the bottleneck?
>
If this is a data related bottleneck you can run a trace of the activity. A
thorough design review wouldn't hurt - this should include validation of the
data access patterns as well as line by line source code walk through.|||"Mark J. McGinty" <mmcginty@.spamfromyou.com> wrote in message
news:#InvFiS2FHA.3244@.tk2msftngp13.phx.gbl...
> "Eric Margheim" <NOSPAM***eric@.prism-grp.com***NOSPAM> wrote in message
> news:u%23op52m1FHA.460@.TK2MSFTNGP15.phx.gbl...
of
clears
a
show
> Have you considered the possibility of a SQL deadlock? Execute sp_who2
when
> the condition occurs again, to see if your [SQL] process is being blocked
by
> another. If that is the case, you can use Enterprise Manager
> (Management->Current Activity->Process Info) to investigate further. From
> there, by double-clicking a process item, you can [usually] view the last
> SQL statement executed. From there you may or may not have your work cut
> out for you, depending on the circumstances, of course.
>
Thanks Mark. Yes I have considered that. Whenever this occurs I have the
db team look at SQL. Sometimes our problem is with database load/locking
but in the cases I'm trying to debug the database is quiet.
Sunday, February 12, 2012
collection name question
1 of my SQL 2000 servers has few databases that acts as backend for web based
..NET applications, most of them is in English and they have collection name:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db which
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIA
Hi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>
..NET applications, most of them is in English and they have collection name:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db which
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIA
Hi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>
collection name question
1 of my SQL 2000 servers has few databases that acts as backend for web base
d
.NET applications, most of them is in English and they have collection name
:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db whic
h
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIAHi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>
d
.NET applications, most of them is in English and they have collection name
:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db whic
h
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIAHi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>
collection name question
1 of my SQL 2000 servers has few databases that acts as backend for web based
.NET applications, most of them is in English and they have collection name:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db which
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIAHi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
--
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>
.NET applications, most of them is in English and they have collection name:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db which
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIAHi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
--
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>
Friday, February 10, 2012
Collation problem with SQL 2000
I need to migrate an application from SQL 7.0 to SQL 2000. I know
that they use different collations, and this causes problems when
7.0 applications are moved to 2000. I would like to find a
permanent fix (so I'm not happy with using "COLLATE" in future
stored procedures) and I'd like to keep the default 2000 collation
(Latin1_General_CI_AS) in order to avoid problems if the
application needs to be moved to another 2000 server in the future.
So the only option is to change the collation of the restored DB.
What is the most efficient way of doing this?
Thanks,
that they use different collations, and this causes problems when
7.0 applications are moved to 2000. I would like to find a
permanent fix (so I'm not happy with using "COLLATE" in future
stored procedures) and I'd like to keep the default 2000 collation
(Latin1_General_CI_AS) in order to avoid problems if the
application needs to be moved to another 2000 server in the future.
So the only option is to change the collation of the restored DB.
What is the most efficient way of doing this?
Thanks,
Marco"Marco" <mdi00@.hotmail.com> wrote in message
news:1106659656.008295.140310@.c13g2000cwb.googlegr oups.com...
>I need to migrate an application from SQL 7.0 to SQL 2000. I know
> that they use different collations, and this causes problems when
> 7.0 applications are moved to 2000. I would like to find a
> permanent fix (so I'm not happy with using "COLLATE" in future
> stored procedures) and I'd like to keep the default 2000 collation
> (Latin1_General_CI_AS) in order to avoid problems if the
> application needs to be moved to another 2000 server in the future.
> So the only option is to change the collation of the restored DB.
> What is the most efficient way of doing this?
> Thanks,
> Marco
ALTER DATABASE can change a database's collation, and ALTER TABLE can change
a single column's collation. I seem to remember changing the database's
collation once and discovering that it didn't change the collation of
existing tables, only new ones, so make sure you test properly first.
Simon|||Marco (mdi00@.hotmail.com) writes:
> I need to migrate an application from SQL 7.0 to SQL 2000. I know
> that they use different collations, and this causes problems when
> 7.0 applications are moved to 2000. I would like to find a
> permanent fix (so I'm not happy with using "COLLATE" in future
> stored procedures) and I'd like to keep the default 2000 collation
> (Latin1_General_CI_AS) in order to avoid problems if the
> application needs to be moved to another 2000 server in the future.
> So the only option is to change the collation of the restored DB.
> What is the most efficient way of doing this?
You will need to bulk out the data, build the database from scripts
and reload data.
But I would only do this if this agrees with business requirements. If
you don't have an SQL 2000 installation, you can install with the
collation of your preference. If there already is an SQL 2000 instance
on the box with a different collation, one option is to install a
second instance on the box.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
Subscribe to:
Posts (Atom)