Hi there,

these are the scenarios i have come across (considering the connection pool
max=100).

1. A c# Windows app that will be used by say 1000 users concurrently.
2. A c# windows app that will be used by 20-30 users concurrently.

In a real world situation, what would be a better solution:
a) Connecting to the database on application startup, and closeing the
connection on Application exit or
b) Starting the app, disconnected, and then everytime the database is
required - connect, do sql call, and disconnect the connection to release it
to the other users?

Also, what kind of licencing implications would i come across in these
scenarios?

Thanks in advance,
Paul

The connection pool has very little if any bearing on a Windows Forms
application. The pool is created on the individual clients--not on the
server. As I describe in Chapter 9, I think it's more efficient to manage
your WF application connections by opening and holding one or more
connections--one for input one for output. SQL Server is capable of handling
thousands of connections--especially since the applications will not be
using them most of the time (in a typical design).

AFA licensing, I expect you'll need to read your EULA to see if you've
signed a CAL license or CPU license that limits the number of connected
users (connections don't usually count) or simply the number of CPUs. No,
I'm no licensing expert. I stepped away from law and went to Vietnam
instead.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
Between now and Nov. 6th 2006 you can sign up for a substantial discount.
Look for the "Early Bird" discount checkbox on the registration form...
-----------------------------------------------------------------------------------------------------------------------


Microsoft MVP, Author, Mentor
Microsoft MVP
"Milsnips" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Hi there,
>
> these are the scenarios i have come across (considering the connection
> pool max=100).
>
> 1. A c# Windows app that will be used by say 1000 users concurrently.
> 2. A c# windows app that will be used by 20-30 users concurrently.
>
> In a real world situation, what would be a better solution:
> a) Connecting to the database on application startup, and closeing the
> connection on Application exit or
> b) Starting the app, disconnected, and then everytime the database is
> required - connect, do sql call, and disconnect the connection to release
> it to the other users?
>
> Also, what kind of licencing implications would i come across in these
> scenarios?
>
> Thanks in advance,
> Paul
>

Hi William,

Thanks for your valuable input. i also think if its for a smaller number of
users probably best to open the connection at start of application, and
close it at the end of the application.

As for the licencing, i think most likely a CPU licence will be used in this
scenario therefore the number of users wont matter.

thanks,
Paul
"William (Bill) Vaughn" <billva@NoSpamAtAll_betav.com> wrote in message
news:%(E-Mail Removed)...
> The connection pool has very little if any bearing on a Windows Forms
> application. The pool is created on the individual clients--not on the
> server. As I describe in Chapter 9, I think it's more efficient to manage
> your WF application connections by opening and holding one or more
> connections--one for input one for output. SQL Server is capable of
> handling thousands of connections--especially since the applications will
> not be using them most of the time (in a typical design).
>
> AFA licensing, I expect you'll need to read your EULA to see if you've
> signed a CAL license or CPU license that limits the number of connected
> users (connections don't usually count) or simply the number of CPUs. No,
> I'm no licensing expert. I stepped away from law and went to Vietnam
> instead.
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> INETA Speaker
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> __________________________________
> Visit www.hitchhikerguides.net to get more information on my latest book:
> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
> Between now and Nov. 6th 2006 you can sign up for a substantial discount.
> Look for the "Early Bird" discount checkbox on the registration form...
> -----------------------------------------------------------------------------------------------------------------------
>
>
> Microsoft MVP, Author, Mentor
> Microsoft MVP
> "Milsnips" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> Hi there,
>>
>> these are the scenarios i have come across (considering the connection
>> pool max=100).
>>
>> 1. A c# Windows app that will be used by say 1000 users concurrently.
>> 2. A c# windows app that will be used by 20-30 users concurrently.
>>
>> In a real world situation, what would be a better solution:
>> a) Connecting to the database on application startup, and closeing the
>> connection on Application exit or
>> b) Starting the app, disconnected, and then everytime the database is
>> required - connect, do sql call, and disconnect the connection to release
>> it to the other users?
>>
>> Also, what kind of licencing implications would i come across in these
>> scenarios?
>>
>> Thanks in advance,
>> Paul
>>
>
>

Right. Consider that SQL Server is very different from its competitors in
that per-connection overhead is relatively low. SQL Server works kinda like
the phone company central office. While there are thousands of phone wires
connected to the CO, only a small fraction of them are active at any one
time. If everyone picks up their phone at once, the system is designed to
service them, but with significant degradation in performance. We ran SQL
Server on a 386/33 system on the MS campus that supported over 1000
connections. I expect a well-oiled server can do as well running today's
operating systems and more efficient versions of SQL Server.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
Between now and Nov. 6th 2006 you can sign up for a substantial discount.
Look for the "Early Bird" discount checkbox on the registration form...
-----------------------------------------------------------------------------------------------------------------------


Microsoft MVP, Author, Mentor
Microsoft MVP
"Milsnips" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi William,
>
> Thanks for your valuable input. i also think if its for a smaller number
> of users probably best to open the connection at start of application, and
> close it at the end of the application.
>
> As for the licencing, i think most likely a CPU licence will be used in
> this scenario therefore the number of users wont matter.
>
> thanks,
> Paul
> "William (Bill) Vaughn" <billva@NoSpamAtAll_betav.com> wrote in message
> news:%(E-Mail Removed)...
>> The connection pool has very little if any bearing on a Windows Forms
>> application. The pool is created on the individual clients--not on the
>> server. As I describe in Chapter 9, I think it's more efficient to manage
>> your WF application connections by opening and holding one or more
>> connections--one for input one for output. SQL Server is capable of
>> handling thousands of connections--especially since the applications will
>> not be using them most of the time (in a typical design).
>>
>> AFA licensing, I expect you'll need to read your EULA to see if you've
>> signed a CAL license or CPU license that limits the number of connected
>> users (connections don't usually count) or simply the number of CPUs. No,
>> I'm no licensing expert. I stepped away from law and went to Vietnam
>> instead.
>>
>> --
>> ____________________________________
>> William (Bill) Vaughn
>> Author, Mentor, Consultant
>> Microsoft MVP
>> INETA Speaker
>> www.betav.com/blog/billva
>> www.betav.com
>> Please reply only to the newsgroup so that others can benefit.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> __________________________________
>> Visit www.hitchhikerguides.net to get more information on my latest book:
>> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
>> Between now and Nov. 6th 2006 you can sign up for a substantial discount.
>> Look for the "Early Bird" discount checkbox on the registration form...
>> -----------------------------------------------------------------------------------------------------------------------
>>
>>
>> Microsoft MVP, Author, Mentor
>> Microsoft MVP
>> "Milsnips" <(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>>> Hi there,
>>>
>>> these are the scenarios i have come across (considering the connection
>>> pool max=100).
>>>
>>> 1. A c# Windows app that will be used by say 1000 users concurrently.
>>> 2. A c# windows app that will be used by 20-30 users concurrently.
>>>
>>> In a real world situation, what would be a better solution:
>>> a) Connecting to the database on application startup, and closeing the
>>> connection on Application exit or
>>> b) Starting the app, disconnected, and then everytime the database is
>>> required - connect, do sql call, and disconnect the connection to
>>> release it to the other users?
>>>
>>> Also, what kind of licencing implications would i come across in these
>>> scenarios?
>>>
>>> Thanks in advance,
>>> Paul
>>>
>>
>>
>
>