I was going to say that the licensing was concurrent users but I think
there is a Gotcha with 2000. I can't remember Doh.

Using components isn't any lesser than the code method just as C
programmers will probably tell me what the hell am I doing with VB. C
programmers can go and OOP off as far as I am concerned.

What struck me was is my method of using a class object declared public
throughout the app a bad method or good. Certainly it's a hell of a lot
easier than finding those connection strings and parameters all over the
place whether it is a good method or bad method I don't know.

What I do know is I love SQL2000 and ADO2.5 / 2.6 actually but I believe
they both can do the following.

To create my public class I need my Bas module and the Sub Main Proc to
start up from.

<Bas Module.>
Public DTLConnection As clsConnection

Sub Main()
Set DTLConnection = New clsConnection
DTLConnection.ServerName = GetSetting(App.Title, "Logon", "Server")
DTLConnection.DataBaseName = GetSetting(App.Title, "Logon", "Database")
DTLConnection.UserName = GetSetting(App.Title, "Logon", "User")
DTLConnection.Password = GetSetting(App.Title, "Logon", "Password")
DTLConnection.Connect
If DTLConnection.Connection Is Nothing Then
frmSQLLogin.Show
Else
Set Login = New clsLogin
frmLogin.Show
End If
End Sub
</Bas File.>

<Class Module. clsConnection>

Private mConnection As adodb.Connection
Private mServerName As String
Private mDataBaseName As String
Private mUserName As String
Private mPassword As String

Public Property Let ServerName(ByVal newValue As String)
mServerName = newValue
End Property
Public Property Let DataBaseName(ByVal newValue As String)
mDataBaseName = newValue
End Property
Public Property Let UserName(ByVal newValue As String)
mUserName = newValue
End Property
Public Property Let Password(ByVal newValue As String)
mPassword = newValue
End Property
Public Property Get Connection() As adodb.Connection
Set Connection = mConnection
End Property
Public Sub Connect()
On Error GoTo Err_Hand
Set mConnection = New adodb.Connection
Dim strConnection As String
strConnection = "Provider=SQLOLEDB.1;Initial Catalog=" & mDataBaseName &
";Data Source=" & mServerName
mConnection.Open strConnection, mUserName, mPassword
If Err.Number = 0 Then
SaveSetting App.Title, "Logon", "Server", mServerName
SaveSetting App.Title, "Logon", "Database", mDataBaseName
SaveSetting App.Title, "Logon", "User", mUserName
SaveSetting App.Title, "Logon", "Password", mPassword
End If

Exit_Sub:
Exit Sub

Err_Hand:
MsgBox Err.Description, vbCritical, "SQL Logon Error"
Err.Clear
Set mConnection = Nothing
Resume Exit_Sub
End Sub

</Class Module. clsConnection>


Then anywhere in the app I can call my connection object
'DtlConnection.Connection' all pretty standard stuff.
What I really like is the simplicity of called parameterised stored
procedures and there performance.

<SQL SP>
ALTER PROCEDURE dbo.Login
(@UserName nvarchar(50),
@Password nvarchar(50))
AS SELECT     Uid, First, Middle, Last
FROM         dbo.Users
WHERE     (UserName = @UserName) AND (Password = @Password)
</SQL SP>

<Form Code>
Dim RS1 As adodb.Recordset
    Set RS1 = New adodb.Recordset
    
    DTLConnection.Connection.Login LCase(txtUserName.Text) & " ",
txtPassword.Text & " ", RS1
    
    If Not RS1.EOF Then
        'place code to here to pass the
        'success to the calling sub
        'setting a global var is the easiest
     Login.Uid = RS1(0)
     Login.First = RS1(1)
     Login.Middle = RS1(2)
     Login.Last = RS1(3)
        frmContactList.Show
        Unload Me
    Else
        MsgBox "Invalid UserName / Password, try again!", , "Login"
        txtPassword.SetFocus
        SendKeys "{Home}+{End}"
    End If
</Form Code>

You just name the SP as part of the connection object model followed by
the parameters and a recordset dependent on query type. I rather like
that.

Thanks
Stuart

Ps. Is someone going to tell me this is bad practise ?
Also the Login.Uid is just part of another public class.


-----Original Message-----
From: Tim Mccurdy [mailto:tmccurdy@c...] 
Sent: Thursday, July 12, 2001 4:29 PM
To: professional vb
Subject: [pro_vb] RE: ADO and SQL Server license

No.  I believe the Connections into SQL Server are concurrent.  But I
also
believe they have something to do with the number of User Logins defined
in
the "Security" section in SQL Server.  There was another POST out here
about
Connection pooling and how ADO looks for a Connection object with the
exact
same parameters and connects other Connection objects through the same
thread rather than making a whole new connection.

One way to minimize connections to SQL, is by using Disconnected
Recordsets.
Also, you only need 1 connection per Client app (so why are you using
more?).  Are you using the ADODC Control?  If so, get rid of it (LOL!)
and
do it through code.

-----Original Message-----
From: Mark.Chen [mailto:Mark.Chen@s...]
Sent: Thursday, July 12, 2001 10:32 AM
To: professional vb
Subject: [pro_vb] ADO and SQL Server license



Hi there,

When we access SQL server, does one ADO connection requires one SQL
license?
Or does one running application requires one license?

I have some forms that has 5 or more ADO's. The thought that each of
them
might need a license gives me a shiver. Hope that is not the case!

Mark