Showing posts with label calls. Show all posts
Showing posts with label calls. Show all posts

Friday, March 30, 2012

Page break and subreports

I have a main report that calls subreports. When a subreport has enough data such that it will not fit into the remaining area of the current page the renderer inserts a page break leaving alot of ugly white space. Is there any way to sop this behaviour? This seems like a very basic thing.

not sure is this is the exact reason, but are u using 8.5 * 11 layout for subreport also, if yes u need to decrease it as per your req. because a ful page cannot be accomodated in a page and so ssrs inserts a page break

Priyank

|||

Priyank,

All of the subreports and the main report for that matter are 8.5 x 11 but what would I change them to? Let me give you an example of my problem. Lets say the first sub report takes up three inches of the first page when rendered. If the second sub report takes up less than the remaining space (5.5 inches) it prints on the same page otherwise it page breaks and starts on a new page. Since the subreports can vary in rendered length depending on data I have no idea what their size will be.

Another thread stated that subreports operate under and assumed KeepTogether. While this may explain what is happening it does not resolve the issue.

Monday, March 26, 2012

Package works in BIDS, but not in SQL Server 2005

Most of my packages that I've created in BIDS will NOT run in SQL Server 2005. The simplest one that I have fails during a script task that calls external managed code. I've done all the steps outlined in "Referencing Other Assemblies...", but I'm still getting "Object reference not set to an instance of an object." Here's a sample of a script that's having a problem. The line in green is the one that seems to be cause of the error. This is extremely frustrating. This code will even run from a command line console without error. Why is it so difficult to deploy one of these projects with managed code?

Code Snippet

Public Sub Main()
Dim variable1 As String = DirectCast(Dts.Variables("packagevariable1").Value, String)
Dim variable2 As String = DirectCast(Dts.Variables("packagevariable2").Value, String)
Dim variable3 As Integer = DirectCast(Dts.Variables("packagevariable3").Value, Integer)
Dim variable4 As String = DirectCast(Dts.Variables("packagevariable4").Value, String)
Dim filePath As String = DirectCast(Dts.Variables("filePath").Value, String)
Dim variable5 As String = DirectCast(Dts.Variables("packagevariable5").Value, String)
Dim results As Boolean
Dim fileGenerator As IProviderInterface
Dim intFactory As integrationServiceFactory = New ProviderIntegrationServiceFactory()

fileGenerator = intFactory.GetProviderEnrollmentGenerator(variable2, variable5)
results = fileGenerator.GenerateFile(variable3, variable1, filePath, variable2)

If results Then
Dts.TaskResult = Dts.Results.Success
Else
Dts.TaskResult = Dts.Results.Failure
End If

End Sub

Can you be more specific what you mean by "run in SQL Server"? How are these packages being executed?

What other types of activities are failing in your packages? Is it always related to external code?

My thinking based on what you've given so far is that you're trying to load and execute packages from inside a CLR stored procedure. When you do that, you're using SQL's hosted CLR and are subject to SQL's security constraints, such as the Host Protection Attributes.

SQL CLR will deny execution of framework code that has these attributes.
ExternalProcessMgmt ExternalThreading MayLeakOnAbort SecurityInfrastructure SelfAffectingProcessMgmnt SelfAffectingThreading SharedState Synchronization UI |||Primarily, I'm trying to execute this in a SQL job. However, if I execute it from Integration Services, the result is the same. My errors seem to be related to the external code, but I have 15 packages that all use some external code. Other activities that are failing also include decrypting files, but again, these are run in scripts that use external code.
|||

Dan Wheeler wrote:

Primarily, I'm trying to execute this in a SQL job. However, if I execute it from Integration Services, the result is the same. My errors seem to be related to the external code, but I have 15 packages that all use some external code.

"if I execute it from Integration Services, the result is the same". I don't know if that means BIDS or something else, and if "the same" means success or failure. I'm mostly going off your subject that the package works in BIDS, but not from a SQL Agent job.

The difference between executing it from BIDS and from a job is usually just the security context. Under BIDS, it inherits your permissions and under SQL Agent, it is whatever account the agent runs under, which is rarely the same. Anything going on in that code that might be affected by those different permissions? Accessing remote or secured drives or files, perhaps?

There is also another affect of the different user context that I don't see any evidence of here, but gets people all the time. That is that by default, SSIS encrypts sensitive data using a user key. When the package is executed by another user (i.e. SQL Agent), this sensitive data (passwords, mostly) are not available. See threads and documentation for "ProtectionLevel" for more information if you think that might be a factor.

|||

JayH wrote:

"if I execute it from Integration Services, the result is the same". I don't know if that means BIDS or something else, and if "the same" means success or failure. I'm mostly going off your subject that the package works in BIDS, but not from a SQL Agent job."


It means that they both fail to execute the package.

The only thing remote in this situation are the databases. This package is not failing with database connectivity issues. My security context is a limited user. What permissions would SQL Agent need?

The packages are password encrypted. I provide the password when creating the SQL job. When I execute the package in Integration Services, I provide the password. Therefore, I don't think it is a protection level issue.
|||

Dan Wheeler wrote:

JayH wrote:

"if I execute it from Integration Services, the result is the same". I don't know if that means BIDS or something else, and if "the same" means success or failure. I'm mostly going off your subject that the package works in BIDS, but not from a SQL Agent job."


It means that they both fail to execute the package.

The only thing remote in this situation are the databases. This package is not failing with database connectivity issues. My security context is a limited user. What permissions would SQL Agent need?

The packages are password encrypted. I provide the password when creating the SQL job. When I execute the package in Integration Services, I provide the password. Therefore, I don't think it is a protection level issue.

I'm still confused about whether the packages run in BIDS or not. If you can call your external code from a simple test harness, then it should work from BIDS.

The error indicates that either GetProviderEnrollmentGenerator is returning Nothing, or that the error is being generated from inside GenerateFile. Is it possible that the variables you're passing into either one of those are not what you think they are? Have you put MessageBoxes in the script to display those values? Being totally agnostic about your code, I'd suggest writing those variables out to a file or something where you can get them verbatim and then calling your external code from a test harness with those values.

|||As the subject states, these packages all execute without error in BIDS. In the first post, I note that I can run this exact code from a console app. I've already created a test harness for this purpose. Since I'm trying to execute this in Integration Services, will the MsgBox's still show up?|||

Dan Wheeler wrote:

As the subject states, these packages all execute without error in BIDS.
Quote "Dan Wheeler"
This code will even run from a command line console without error.


(as you can see, I've already created a test harness for this purpose) Since I'm trying to execute this in Integration Services, will the MsgBox's still show up?

Sorry, I think I'm confused about your use of "Integration Services". I couldn't tell if you meant BIDS or not. I also don't recall seeing that about your console app in the original post.

No, MessageBoxes will not show up if you execute from dtexec (i.e. the agent job). I was thinking about BIDS at that point.
|||Anyone else have anything to offer? I've created a deployment package and still no success.
|||

What if you try running a batch file from the agent job?

My experience mirrors Jay's on this: I think the error is security related. Does the the account that SQL Server or the agent is running under have access to all the files and folders used - not just by the package, but also by the .NET component?

sql

Saturday, February 25, 2012

Overlapping times

Hi All,
I have a table which logs calls called calls There are 3 main columns
user_id, starttime,endtime
I would like to run a query (a self-join i guess) which lists all
overlapping calls for a particular user_id.
In theory it should not be possible for a user to make 2 or more
simulataneous calls.
Any help would be greatly appreciated.
SergioYOu should only compare the start time with the data you have to see wheter
it overlaps
Select UserID from YourTable t1
inner join Yourtable t2
on userid = userid
Where t1.Starttime between t2.starttime and t2.endtime
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Serghios" <Serghios.Florides@.elthion.com> schrieb im Newsbeitrag
news:ORD1hXdZFHA.3648@.TK2MSFTNGP14.phx.gbl...
> Hi All,
> I have a table which logs calls called calls There are 3 main columns
> user_id, starttime,endtime
> I would like to run a query (a self-join i guess) which lists all
> overlapping calls for a particular user_id.
> In theory it should not be possible for a user to make 2 or more
> simulataneous calls.
> Any help would be greatly appreciated.
> Sergio
>
>
>|||Sergio, try,
select c1.userid, c1.starttime as s1, c1.endtime as e1,
c2.starttime as s2, c2.endtime as e2
from calls as c1
join calls as c2
on c1.key_col <> c2.key_col
and c1.userid = c2.userid
and c1.starttime <= c2.endtime
and c1.endtime >= c2.starttime
-- not tested
BG, SQL Server MVP
www.SolidQualityLearning.com
"Serghios" <Serghios.Florides@.elthion.com> wrote in message
news:ORD1hXdZFHA.3648@.TK2MSFTNGP14.phx.gbl...
> Hi All,
> I have a table which logs calls called calls There are 3 main columns
> user_id, starttime,endtime
> I would like to run a query (a self-join i guess) which lists all
> overlapping calls for a particular user_id.
> In theory it should not be possible for a user to make 2 or more
> simulataneous calls.
> Any help would be greatly appreciated.
> Sergio
>
>
>|||Unfortunately this query returns all rows in my table
"Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote in
message news:ON1yhjdZFHA.1152@.tk2msftngp13.phx.gbl...
> YOu should only compare the start time with the data you have to see
> wheter it overlaps
> Select UserID from YourTable t1
> inner join Yourtable t2
> on userid = userid
> Where t1.Starttime between t2.starttime and t2.endtime
>
> --
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "Serghios" <Serghios.Florides@.elthion.com> schrieb im Newsbeitrag
> news:ORD1hXdZFHA.3648@.TK2MSFTNGP14.phx.gbl...
>|||That's because a period always overlaps with itself. You can eliminate the
self match by filtering t1.key <> t2.key, assuming you have a single column
key in the table. If the key is composite, use:
on t1.key1 <> t2.key1 or t1.key2 <> t2.key2, etc.
BG, SQL Server MVP
www.SolidQualityLearning.com
"Serghios" <Serghios.Florides@.elthion.com> wrote in message
news:ODHsQrdZFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Unfortunately this query returns all rows in my table
>
> "Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
> in message news:ON1yhjdZFHA.1152@.tk2msftngp13.phx.gbl...
>|||This can be more complicated that it looks on the surface. An overlap can ha
ppen
in one of two ways:
1. The start date of one range is between the start and end date of another
range.
2. The end date of one range is between the start and end date of another ra
nge.
It gets a little more complicated if end dates can be null.
Assuming no nulls, you would have something like:
Select F1..Fn
From Table As T1
Join Table As T2
On T1.PK <> T2.PK
And T1.User_Id = T2.User_Id
And (
(T1.Start >= T2.Start
And (T1.Start <= T2.End Or T1.End <= T2.End))
Or (T2.Start >= T1.Start
And (T2.Start <= T1.End Or T2.End <= T1.End))
)
If the dates can be null, you'll have to decide how that should be interpret
ed.
For example, if a null end date means that there is no end, then you would w
ant
to replace the end date with an arbitrarily large date (e.g. 9999-12-31).
Thomas
"Serghios" <Serghios.Florides@.elthion.com> wrote in message
news:ORD1hXdZFHA.3648@.TK2MSFTNGP14.phx.gbl...
> Hi All,
> I have a table which logs calls called calls There are 3 main columns
> user_id, starttime,endtime
> I would like to run a query (a self-join i guess) which lists all overlapp
ing
> calls for a particular user_id.
> In theory it should not be possible for a user to make 2 or more simulatan
eous
> calls.
> Any help would be greatly appreciated.
> Sergio
>
>
>|||Think about this in reverse: Two events do not overlap if one ends
before the other begins, or if it begins after the end of other one.
Write that and then negate it.
SELECT E1.*
FROM Events AS E1,
Events AS E2
WHERE E1.event_key <> E2.event_key
AND E1.user_id = E2.user_id
AND NOT (E1.start_time > E2.end_time
OR E1.end_time < E2.end_time)
Or you can use DeMorgan's law on the last predicate:
AND (E1.start_time <= E2.end_time
AND E1.end_time >= E2.end_time)
There is also an OVERLAPS predicate in SQL-92 for this purpose,but it
is a bit tricky.|||Thomas,
Itzik's solution is simpler and equivalent. In words, it may be
easier to think of in terms of two lives. As long as people do
not die before they are born (something you would implement
as a constraint in the data model), the lives of X and Y
overlap if and only if X died after Y was born and Y died after
X was born. It seems too simple to work, but it works. Your
comment about NULL end dates is important. Here's one
solution to handle NULL meaning "not ended yet"
...
and coalesce(X.End,'99991231') > Y.Start
and coalesce(Y.End,'99991231') > X.Start
Steve Kass
Drew University
Thomas Coleman wrote:

>This can be more complicated that it looks on the surface. An overlap can h
appen
>in one of two ways:
>1. The start date of one range is between the start and end date of another
>range.
>2. The end date of one range is between the start and end date of another r
ange.
>It gets a little more complicated if end dates can be null.
>Assuming no nulls, you would have something like:
>
>Select F1..Fn
>From Table As T1
> Join Table As T2
> On T1.PK <> T2.PK
> And T1.User_Id = T2.User_Id
> And (
> (T1.Start >= T2.Start
> And (T1.Start <= T2.End Or T1.End <= T2.End))
> Or (T2.Start >= T1.Start
> And (T2.Start <= T1.End Or T2.End <= T1.End))
> )
>If the dates can be null, you'll have to decide how that should be interpre
ted.
>For example, if a null end date means that there is no end, then you would
want
>to replace the end date with an arbitrarily large date (e.g. 9999-12-31).
>
>Thomas
>
>"Serghios" <Serghios.Florides@.elthion.com> wrote in message
>news:ORD1hXdZFHA.3648@.TK2MSFTNGP14.phx.gbl...
>
>
>|||On the contrary, the do not produce the same results.
Create Table Dates
(
Id Int Primary Key
, StartDate DateTime
, EndDate DateTime
)
Insert Dates(Id, StartDate, EndDate) Values(1, '20050101', '20050131')
Insert Dates(Id, StartDate, EndDate) Values(2, '20050115', '20050131')
--Original post
Select *
From Dates As D1
Join Dates As D2
On D1.Id <> D2.Id
Where D1.StartDate Between D2.StartDate And D2.EndDate
--My overlaps version
Select *
From Dates As D1
Join Dates As D2
On D1.Id <> D2.Id
Where (D1.StartDate >= D2.StartDate
And (D1.StartDate <= D2.EndDate Or D1.EndDate <= D2.EndDate))
Or (D2.StartDate >= D1.StartDate
And (D2.StartDate <= D1.EndDate Or D2.EndDate <= D1.EndDate))
--equivalent to Joe's version
Select *
From Dates As D1
Join Dates As D2
On D1.Id <> D2.Id
Where Not (D1.StartDate > D2.EndDate Or D1.EndDate < D2.EndDate)
--equivalent to Joe's version using DeMorgan's law
Select *
From Dates As D1
Join Dates As D2
On D1.Id <> D2.Id
Where D1.StartDate <= D2.EndDate And D1.EndDate >= D2.EndDate
Notice that in the first select statement only Item#2 shows as having an ove
rlap
whereas both values show in the second select statement. The problem with on
ly
looking at the start date on a given row is that it does not account for the
End
Date of that row overlapping with an existing range. Rather, it only account
s
for the overlapped range.
I actually modified my results from the Ovelaps specification in the SQL92 s
pec.
Joe's simplified version is actually cleaner and just as accurate. Thanks Jo
e.
Think I'll use that.
Thomas
"Steve Kass" <skass@.drew.edu> wrote in message
news:uzAJechZFHA.3960@.TK2MSFTNGP10.phx.gbl...
> Thomas,
> Itzik's solution is simpler and equivalent. In words, it may be
> easier to think of in terms of two lives. As long as people do
> not die before they are born (something you would implement
> as a constraint in the data model), the lives of X and Y
> overlap if and only if X died after Y was born and Y died after
> X was born. It seems too simple to work, but it works. Your
> comment about NULL end dates is important. Here's one
> solution to handle NULL meaning "not ended yet"
> ...
> and coalesce(X.End,'99991231') > Y.Start
> and coalesce(Y.End,'99991231') > X.Start
> Steve Kass
> Drew University
>
> Thomas Coleman wrote:
>|||The only downside to your approach Joe is when one range is contained within
another. Granted, we are now getting into the semantics of what it really me
ans
to "overlap". However, if you wanted "overlap or contained within", your
algorithm would not work.
For example, using the structure below imagine we have:
Insert Dates(Id, StartDate, EndDate) Values(1, '20050101', '20050131')
Insert Dates(Id, StartDate, EndDate) Values(2, '20050115', '20050130')
This will show that the first item overlaps the second, but not the reverse.
That can easily be fixed by adding a clause that checks for containment like
so:
Select *
From Dates As D1
Join Dates As D2
On D1.Id <> D2.Id
Where D1.StartDate <= D2.EndDate And D1.EndDate >= D2.EndDate
Or (D1.StartDate >= D2.StartDate And D1.EndDate <= D2.EndDate)
Thomas
"Thomas Coleman" <replyingroup@.anywhere.com> wrote in message
news:%23tTYa3hZFHA.3876@.TK2MSFTNGP12.phx.gbl...
> On the contrary, the do not produce the same results.
> Create Table Dates
> (
> Id Int Primary Key
> , StartDate DateTime
> , EndDate DateTime
> )
> Insert Dates(Id, StartDate, EndDate) Values(1, '20050101', '20050131')
> Insert Dates(Id, StartDate, EndDate) Values(2, '20050115', '20050131')
> --Original post
> Select *
> From Dates As D1
> Join Dates As D2
> On D1.Id <> D2.Id
> Where D1.StartDate Between D2.StartDate And D2.EndDate
> --My overlaps version
> Select *
> From Dates As D1
> Join Dates As D2
> On D1.Id <> D2.Id
> Where (D1.StartDate >= D2.StartDate
> And (D1.StartDate <= D2.EndDate Or D1.EndDate <= D2.EndDate))
> Or (D2.StartDate >= D1.StartDate
> And (D2.StartDate <= D1.EndDate Or D2.EndDate <= D1.EndDate))
> --equivalent to Joe's version
> Select *
> From Dates As D1
> Join Dates As D2
> On D1.Id <> D2.Id
> Where Not (D1.StartDate > D2.EndDate Or D1.EndDate < D2.EndDate)
> --equivalent to Joe's version using DeMorgan's law
> Select *
> From Dates As D1
> Join Dates As D2
> On D1.Id <> D2.Id
> Where D1.StartDate <= D2.EndDate And D1.EndDate >= D2.EndDate
>
> Notice that in the first select statement only Item#2 shows as having an
> overlap whereas both values show in the second select statement. The probl
em
> with only looking at the start date on a given row is that it does not acc
ount
> for the End Date of that row overlapping with an existing range. Rather, i
t
> only accounts for the overlapped range.
> I actually modified my results from the Ovelaps specification in the SQL92
> spec. Joe's simplified version is actually cleaner and just as accurate.
> Thanks Joe. Think I'll use that.
>
> Thomas
>
> "Steve Kass" <skass@.drew.edu> wrote in message
> news:uzAJechZFHA.3960@.TK2MSFTNGP10.phx.gbl...
>

Monday, February 20, 2012

Overhead of Multiple SQL Calls

Hey folks,
I've got a client server C# Windows Form app that communicates with a SQL
Server database backend. The number of users is less than 50.
I'm wondering what the difference in overhead is when say:
a) A Stored Procedure is called ten times, returning 1 record each time
VS.
b) The same Stored Procedure is called once returning 10 records
Due to connection pooling I would think the overhead is somewhat negligible,
especially when there's less than 50 users. I know option 'b' would be the
preffered method when it comes to database communication, but is there
really a BIG difference between the two when dealing with this few users?
Thanks!
(also posted on windows.forms newsgroup on Feb 25 with no response)Hi John,
I would think the network traffic would be significantly greater when
submiting 10 calls to get 1 record each as opposed to 1 call to get 10
records. That's automatically 10X the client-to-server network traffic.
Constantly opening and closing connections, as well as maintaining
connections that aren't in use, can use up a lot of resources on SQL Server
also. Now whether this should cause problems with a small number of users
is another story... It probably depends on how they're using the server...
Are they running automated reports that are requesting records one at a time
and might include thousands of separate requests? Or maybe they're just
accessing 30 records/hour on average each?
Connection pooling helps, but it can't compensate completely for a design
flaw.
Are you using C#.NET? If so, you might look into ADO.NET. ADO.NET is
designed to handle a lot of the management issues for you.
Thanks,
Mike C.
"John Smith" <js@.no.com> wrote in message
news:OHFsJQqHFHA.560@.TK2MSFTNGP12.phx.gbl...
> Hey folks,
> I've got a client server C# Windows Form app that communicates with a SQL
> Server database backend. The number of users is less than 50.
> I'm wondering what the difference in overhead is when say:
> a) A Stored Procedure is called ten times, returning 1 record each time
> VS.
> b) The same Stored Procedure is called once returning 10 records
> Due to connection pooling I would think the overhead is somewhat
> negligible,
> especially when there's less than 50 users. I know option 'b' would be
> the
> preffered method when it comes to database communication, but is there
> really a BIG difference between the two when dealing with this few users?
> Thanks!
> (also posted on windows.forms newsgroup on Feb 25 with no response)
>|||You have that many today but what about tomorrow? Seriously you should
always keep scalability in mind when designing the app and the schema. In
your example you are incurring about 10 times the overhead on not only the
server but the network and the client. There certainly may be times when it
might make sense to do it the A way but if you can do it the B way then you
should.
--
Andrew J. Kelly SQL MVP
"John Smith" <js@.no.com> wrote in message
news:OHFsJQqHFHA.560@.TK2MSFTNGP12.phx.gbl...
> Hey folks,
> I've got a client server C# Windows Form app that communicates with a SQL
> Server database backend. The number of users is less than 50.
> I'm wondering what the difference in overhead is when say:
> a) A Stored Procedure is called ten times, returning 1 record each time
> VS.
> b) The same Stored Procedure is called once returning 10 records
> Due to connection pooling I would think the overhead is somewhat
> negligible,
> especially when there's less than 50 users. I know option 'b' would be
> the
> preffered method when it comes to database communication, but is there
> really a BIG difference between the two when dealing with this few users?
> Thanks!
> (also posted on windows.forms newsgroup on Feb 25 with no response)
>

Overhead of Multiple SQL Calls

Hey folks,
I've got a client server C# Windows Form app that communicates with a SQL
Server database backend. The number of users is less than 50.
I'm wondering what the difference in overhead is when say:
a) A Stored Procedure is called ten times, returning 1 record each time
VS.
b) The same Stored Procedure is called once returning 10 records
Due to connection pooling I would think the overhead is somewhat negligible,
especially when there's less than 50 users. I know option 'b' would be the
preffered method when it comes to database communication, but is there
really a BIG difference between the two when dealing with this few users?
Thanks!
(also posted on windows.forms newsgroup on Feb 25 with no response)Hi John,
I would think the network traffic would be significantly greater when
submiting 10 calls to get 1 record each as opposed to 1 call to get 10
records. That's automatically 10X the client-to-server network traffic.
Constantly opening and closing connections, as well as maintaining
connections that aren't in use, can use up a lot of resources on SQL Server
also. Now whether this should cause problems with a small number of users
is another story... It probably depends on how they're using the server...
Are they running automated reports that are requesting records one at a time
and might include thousands of separate requests? Or maybe they're just
accessing 30 records/hour on average each?
Connection pooling helps, but it can't compensate completely for a design
flaw.
Are you using C#.NET? If so, you might look into ADO.NET. ADO.NET is
designed to handle a lot of the management issues for you.
Thanks,
Mike C.
"John Smith" <js@.no.com> wrote in message
news:OHFsJQqHFHA.560@.TK2MSFTNGP12.phx.gbl...
> Hey folks,
> I've got a client server C# Windows Form app that communicates with a SQL
> Server database backend. The number of users is less than 50.
> I'm wondering what the difference in overhead is when say:
> a) A Stored Procedure is called ten times, returning 1 record each time
> VS.
> b) The same Stored Procedure is called once returning 10 records
> Due to connection pooling I would think the overhead is somewhat
> negligible,
> especially when there's less than 50 users. I know option 'b' would be
> the
> preffered method when it comes to database communication, but is there
> really a BIG difference between the two when dealing with this few users?
> Thanks!
> (also posted on windows.forms newsgroup on Feb 25 with no response)
>|||You have that many today but what about tomorrow? Seriously you should
always keep scalability in mind when designing the app and the schema. In
your example you are incurring about 10 times the overhead on not only the
server but the network and the client. There certainly may be times when it
might make sense to do it the A way but if you can do it the B way then you
should.
Andrew J. Kelly SQL MVP
"John Smith" <js@.no.com> wrote in message
news:OHFsJQqHFHA.560@.TK2MSFTNGP12.phx.gbl...
> Hey folks,
> I've got a client server C# Windows Form app that communicates with a SQL
> Server database backend. The number of users is less than 50.
> I'm wondering what the difference in overhead is when say:
> a) A Stored Procedure is called ten times, returning 1 record each time
> VS.
> b) The same Stored Procedure is called once returning 10 records
> Due to connection pooling I would think the overhead is somewhat
> negligible,
> especially when there's less than 50 users. I know option 'b' would be
> the
> preffered method when it comes to database communication, but is there
> really a BIG difference between the two when dealing with this few users?
> Thanks!
> (also posted on windows.forms newsgroup on Feb 25 with no response)
>

Overhead of Multiple SQL Calls

Hey folks,
I've got a client server C# Windows Form app that communicates with a SQL
Server database backend. The number of users is less than 50.
I'm wondering what the difference in overhead is when say:
a) A Stored Procedure is called ten times, returning 1 record each time
VS.
b) The same Stored Procedure is called once returning 10 records
Due to connection pooling I would think the overhead is somewhat negligible,
especially when there's less than 50 users. I know option 'b' would be the
preffered method when it comes to database communication, but is there
really a BIG difference between the two when dealing with this few users?
Thanks!
(also posted on windows.forms newsgroup on Feb 25 with no response)
Hi John,
I would think the network traffic would be significantly greater when
submiting 10 calls to get 1 record each as opposed to 1 call to get 10
records. That's automatically 10X the client-to-server network traffic.
Constantly opening and closing connections, as well as maintaining
connections that aren't in use, can use up a lot of resources on SQL Server
also. Now whether this should cause problems with a small number of users
is another story... It probably depends on how they're using the server...
Are they running automated reports that are requesting records one at a time
and might include thousands of separate requests? Or maybe they're just
accessing 30 records/hour on average each?
Connection pooling helps, but it can't compensate completely for a design
flaw.
Are you using C#.NET? If so, you might look into ADO.NET. ADO.NET is
designed to handle a lot of the management issues for you.
Thanks,
Mike C.
"John Smith" <js@.no.com> wrote in message
news:OHFsJQqHFHA.560@.TK2MSFTNGP12.phx.gbl...
> Hey folks,
> I've got a client server C# Windows Form app that communicates with a SQL
> Server database backend. The number of users is less than 50.
> I'm wondering what the difference in overhead is when say:
> a) A Stored Procedure is called ten times, returning 1 record each time
> VS.
> b) The same Stored Procedure is called once returning 10 records
> Due to connection pooling I would think the overhead is somewhat
> negligible,
> especially when there's less than 50 users. I know option 'b' would be
> the
> preffered method when it comes to database communication, but is there
> really a BIG difference between the two when dealing with this few users?
> Thanks!
> (also posted on windows.forms newsgroup on Feb 25 with no response)
>
|||You have that many today but what about tomorrow? Seriously you should
always keep scalability in mind when designing the app and the schema. In
your example you are incurring about 10 times the overhead on not only the
server but the network and the client. There certainly may be times when it
might make sense to do it the A way but if you can do it the B way then you
should.
Andrew J. Kelly SQL MVP
"John Smith" <js@.no.com> wrote in message
news:OHFsJQqHFHA.560@.TK2MSFTNGP12.phx.gbl...
> Hey folks,
> I've got a client server C# Windows Form app that communicates with a SQL
> Server database backend. The number of users is less than 50.
> I'm wondering what the difference in overhead is when say:
> a) A Stored Procedure is called ten times, returning 1 record each time
> VS.
> b) The same Stored Procedure is called once returning 10 records
> Due to connection pooling I would think the overhead is somewhat
> negligible,
> especially when there's less than 50 users. I know option 'b' would be
> the
> preffered method when it comes to database communication, but is there
> really a BIG difference between the two when dealing with this few users?
> Thanks!
> (also posted on windows.forms newsgroup on Feb 25 with no response)
>