About a RS version and previous conditions of use

I own a Windows Small Bussiness 2003 license which includes SQL server 2000
Standard Edition and additionally came with a version of Reporting Services.
I want to learn and use it (Reporting Services) as a beginner but when I
try to install it a message appears indicating that I need to install or
configure previously two products:
a) Visual Studio .Net 2003
b) IIS 5.0
Do I need both of 'em just to begin doing simple reports?
I supposed a simple use like I could obtain through Crystal reports 7.0 or
so on.
Please, help me.
Probably next year we will migrate to a new version of Microsoft SBS
Is it worth to do efforts with the versions I own nowadays or not?
Thanks alot in advance.
--
sanpetusRS 2000 report designer require some copy of VS 2003 to be installed. In the
past VB.net 2003 was the cheapest way to do this (about $100). I don't know
now. Note that the VB 2005 will not work for this.
In RS 2005 it comes with a version of VS 2005 so no additional purchase is
necessary.
RS is a asp.net application and as such it needs IIS. IIS comes with all
servers. It might need to configured though.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"sanpetus" <sanpetus@.discussions.microsoft.com> wrote in message
news:14FE57B4-A059-4B0F-8539-C9D64CBAA6B6@.microsoft.com...
>I own a Windows Small Bussiness 2003 license which includes SQL server 2000
> Standard Edition and additionally came with a version of Reporting
> Services.
> I want to learn and use it (Reporting Services) as a beginner but when I
> try to install it a message appears indicating that I need to install or
> configure previously two products:
> a) Visual Studio .Net 2003
> b) IIS 5.0
> Do I need both of 'em just to begin doing simple reports?
> I supposed a simple use like I could obtain through Crystal reports 7.0 or
> so on.
> Please, help me.
> Probably next year we will migrate to a new version of Microsoft SBS
> Is it worth to do efforts with the versions I own nowadays or not?
> Thanks alot in advance.
> --
> sanpetus

about 32 bit application and odbc to access 64 bit SQL Server 2005

Hello
Our application currently is running on IIS machine with Windows 2003 32 bit
OS installed and database server machine with Windows 2000 32 bit OS and SQL
server 2000 installed.
We are thinking to upgrade the database server to Windows 2003 64 bit OS and
SQL server 2005 64 bit.
The IIS machine is still on 32 bit OS and application, We are wondering if
there is any problem for 32 bit application and ODBC to access the 64 bit
database?
Thanks in advance
Lionel
No, there is no problem. I least I have seen dozens of similar applications
accesing 64-bit databases.
Most of the connectivity issues I have seen is connecting SQL Server 64-bit
to Oracle but there is always a solution.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"lionel" wrote:

> Hello
> Our application currently is running on IIS machine with Windows 2003 32 bit
> OS installed and database server machine with Windows 2000 32 bit OS and SQL
> server 2000 installed.
> We are thinking to upgrade the database server to Windows 2003 64 bit OS and
> SQL server 2005 64 bit.
> The IIS machine is still on 32 bit OS and application, We are wondering if
> there is any problem for 32 bit application and ODBC to access the 64 bit
> database?
> Thanks in advance
> Lionel
|||Lionel,
Here is a nice article on migrating to 64 bit SQL Server and the drivers it
takes to connect.
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1241693,00.html
The only issue when using a 64 bit OS that I have noticed is on the Jet
(Access) connector which doesnt exist on 64 bit.
/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"Ben Nevarez" <BenNevarez@.discussions.microsoft.com> wrote in message
news:EF862D05-83A0-4F45-A0DE-D12F696E7EE8@.microsoft.com...[vbcol=seagreen]
> No, there is no problem. I least I have seen dozens of similar
> applications
> accesing 64-bit databases.
> Most of the connectivity issues I have seen is connecting SQL Server
> 64-bit
> to Oracle but there is always a solution.
> Hope this helps,
> Ben Nevarez
> Senior Database Administrator
> AIG SunAmerica
>
> "lionel" wrote:

about 32 bit application and odbc to access 64 bit SQL Server 2005

Hello
Our application currently is running on IIS machine with Windows 2003 32 bit
OS installed and database server machine with Windows 2000 32 bit OS and SQL
server 2000 installed.
We are thinking to upgrade the database server to Windows 2003 64 bit OS and
SQL server 2005 64 bit.
The IIS machine is still on 32 bit OS and application, We are wondering if
there is any problem for 32 bit application and ODBC to access the 64 bit
database?
Thanks in advance
LionelNo, there is no problem. I least I have seen dozens of similar applications
accesing 64-bit databases.
Most of the connectivity issues I have seen is connecting SQL Server 64-bit
to Oracle but there is always a solution.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"lionel" wrote:

> Hello
> Our application currently is running on IIS machine with Windows 2003 32 b
it
> OS installed and database server machine with Windows 2000 32 bit OS and S
QL
> server 2000 installed.
> We are thinking to upgrade the database server to Windows 2003 64 bit OS a
nd
> SQL server 2005 64 bit.
> The IIS machine is still on 32 bit OS and application, We are wondering if
> there is any problem for 32 bit application and ODBC to access the 64 bit
> database?
> Thanks in advance
> Lionel|||Lionel,
Here is a nice article on migrating to 64 bit SQL Server and the drivers it
takes to connect.
http://searchsqlserver.techtarget.c...1241693,00.html
The only issue when using a 64 bit OS that I have noticed is on the Jet
(Access) connector which doesnt exist on 64 bit.
/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"Ben Nevarez" <BenNevarez@.discussions.microsoft.com> wrote in message
news:EF862D05-83A0-4F45-A0DE-D12F696E7EE8@.microsoft.com...[vbcol=seagreen]
> No, there is no problem. I least I have seen dozens of similar
> applications
> accesing 64-bit databases.
> Most of the connectivity issues I have seen is connecting SQL Server
> 64-bit
> to Oracle but there is always a solution.
> Hope this helps,
> Ben Nevarez
> Senior Database Administrator
> AIG SunAmerica
>
> "lionel" wrote:
>

about 32 bit application and odbc to access 64 bit SQL Server 2005

Hello
Our application currently is running on IIS machine with Windows 2003 32 bit
OS installed and database server machine with Windows 2000 32 bit OS and SQL
server 2000 installed.
We are thinking to upgrade the database server to Windows 2003 64 bit OS and
SQL server 2005 64 bit.
The IIS machine is still on 32 bit OS and application, We are wondering if
there is any problem for 32 bit application and ODBC to access the 64 bit
database?
Thanks in advance
LionelNo, there is no problem. I least I have seen dozens of similar applications
accesing 64-bit databases.
Most of the connectivity issues I have seen is connecting SQL Server 64-bit
to Oracle but there is always a solution.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"lionel" wrote:
> Hello
> Our application currently is running on IIS machine with Windows 2003 32 bit
> OS installed and database server machine with Windows 2000 32 bit OS and SQL
> server 2000 installed.
> We are thinking to upgrade the database server to Windows 2003 64 bit OS and
> SQL server 2005 64 bit.
> The IIS machine is still on 32 bit OS and application, We are wondering if
> there is any problem for 32 bit application and ODBC to access the 64 bit
> database?
> Thanks in advance
> Lionel|||Lionel,
Here is a nice article on migrating to 64 bit SQL Server and the drivers it
takes to connect.
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1241693,00.html
The only issue when using a 64 bit OS that I have noticed is on the Jet
(Access) connector which doesnt exist on 64 bit.
--
/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"Ben Nevarez" <BenNevarez@.discussions.microsoft.com> wrote in message
news:EF862D05-83A0-4F45-A0DE-D12F696E7EE8@.microsoft.com...
> No, there is no problem. I least I have seen dozens of similar
> applications
> accesing 64-bit databases.
> Most of the connectivity issues I have seen is connecting SQL Server
> 64-bit
> to Oracle but there is always a solution.
> Hope this helps,
> Ben Nevarez
> Senior Database Administrator
> AIG SunAmerica
>
> "lionel" wrote:
>> Hello
>> Our application currently is running on IIS machine with Windows 2003 32
>> bit
>> OS installed and database server machine with Windows 2000 32 bit OS and
>> SQL
>> server 2000 installed.
>> We are thinking to upgrade the database server to Windows 2003 64 bit OS
>> and
>> SQL server 2005 64 bit.
>> The IIS machine is still on 32 bit OS and application, We are wondering
>> if
>> there is any problem for 32 bit application and ODBC to access the 64 bit
>> database?
>> Thanks in advance
>> Lionel

A WTF moment with SSRS....

...no, 'WTF' does not stand for 'Windows Transaction Framework,' LOL. I am writing to complain about what I believe is the annoying behavior of SSRS 2005 SP1. Specifically, I am trying to invoke a very simple MS SQL Server 2005 stored procedure as the data source of a report. This stored proc has an input parameter of type bit. The corresponding report parameter is type Boolean. When prompted for an input value when running the report, I enter a 0 or a 1. Much to my dismay, the SSRS IDE raises an error along the lines of '...error encountered when converting string value to Boolean.' For sake of argument, let's say that my stored proc's parameter were of the int type. I would then be prompted for a whole number parameter value, which I would be able to enter without a problem (no string-to-integer conversion error). What does SSRS not like about passing Boolean values to a stored proc that is expecting a bit? (Is the Boolean value converted to 'TRUE' or 'FALSE' under the covers?) Please advise, or I will be forced to spell out WTF....

TIA,

mattyseltz

...OK, the problem was my own stupidity. When prompted (in the SSRS IDE) for a parameter value for the input stored procedure parameter of type bit, I should have typed either 'False' or 'True', not 0 or 1. I think that is counter-intuitive, because one would execute the stored proc in Query Analyzer using a value of 0 or 1. Oh, well....

mattyseltz

|||IF you create parameter with Boolean type it should works either with False/True or 0/1. I have some reports like you describe and I was able to use False/True or 0/1. Anyway, you solve a problem, it's a main thing :)sql

a strange issue after installing SP3a (SP3a Issue)

when installing "SQL Server Service Pack 3a" on my "SQL Server Personal
Edition", something strange happened to the windows view data in the Tables
and Views, they are showing RightToLeft!!!!?
how can i fix this? and why did it happen?
please help. and if possible email me the solution to ay_tech@.yahoo.com
Thanks!
Ayman
Message posted via http://www.sqlmonster.com
Would Any One help plese on the Issue ?
Message posted via http://www.sqlmonster.com
|||On Wed, 16 Feb 2005 11:05:43 GMT, Ayman AM via SQLMonster.com wrote:

>when installing "SQL Server Service Pack 3a" on my "SQL Server Personal
>Edition", something strange happened to the windows view data in the Tables
>and Views, they are showing RightToLeft!!!!?
>how can i fix this? and why did it happen?
Hi Ayman,
Is this in Enterprise Manager?
Try this: when displaying tables or views, select "Details" from the
"View" menu (I hope that's the English equivalent - I'm using a Dutch
verwion of Windows). Check the left-most heading above the list of table
names - my guess is that you'll find an upward pointing arrowhead in it,
denoting reverse sort on table- or view-name. Click this header once to
select normal sort (the arrowhead will change to point down). Then, use
the "View" menu again to restore your favorite setting (I think, from your
message, that you're using large pictograms - I always have the details
view selected, but that's just personal preference).
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)

a strange issue after installing SP3a (SP3a Issue)

when installing "SQL Server Service Pack 3a" on my "SQL Server Personal
Edition", something strange happened to the windows view data in the Tables
and Views, they are showing RightToLeft!!!!?
how can i fix this? and why did it happen?
please help. and if possible email me the solution to ay_tech@.yahoo.com
Thanks!
Ayman
--
Message posted via http://www.sqlmonster.comWould Any One help plese on the Issue ?
--
Message posted via http://www.sqlmonster.com|||On Wed, 16 Feb 2005 11:05:43 GMT, Ayman AM via SQLMonster.com wrote:
>when installing "SQL Server Service Pack 3a" on my "SQL Server Personal
>Edition", something strange happened to the windows view data in the Tables
>and Views, they are showing RightToLeft!!!!?
>how can i fix this? and why did it happen?
Hi Ayman,
Is this in Enterprise Manager?
Try this: when displaying tables or views, select "Details" from the
"View" menu (I hope that's the English equivalent - I'm using a Dutch
verwion of Windows). Check the left-most heading above the list of table
names - my guess is that you'll find an upward pointing arrowhead in it,
denoting reverse sort on table- or view-name. Click this header once to
select normal sort (the arrowhead will change to point down). Then, use
the "View" menu again to restore your favorite setting (I think, from your
message, that you're using large pictograms - I always have the details
view selected, but that's just personal preference).
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

a strange issue after installing SP3a (SP3a Issue)

when installing "SQL Server Service Pack 3a" on my "SQL Server Personal
Edition", something strange happened to the windows view data in the Tables
and Views, they are showing RightToLeft!!!!?
how can i fix this? and why did it happen?
please help. and if possible email me the solution to ay_tech@.yahoo.com
Thanks!
Ayman
Message posted via http://www.droptable.comWould Any One help plese on the Issue ?
Message posted via http://www.droptable.com|||On Wed, 16 Feb 2005 11:05:43 GMT, Ayman AM via droptable.com wrote:

>when installing "SQL Server Service Pack 3a" on my "SQL Server Personal
>Edition", something strange happened to the windows view data in the Tables
>and Views, they are showing RightToLeft!!!!?
>how can i fix this? and why did it happen?
Hi Ayman,
Is this in Enterprise Manager?
Try this: when displaying tables or views, select "Details" from the
"View" menu (I hope that's the English equivalent - I'm using a Dutch
verwion of Windows). Check the left-most heading above the list of table
names - my guess is that you'll find an upward pointing arrowhead in it,
denoting reverse sort on table- or view-name. Click this header once to
select normal sort (the arrowhead will change to point down). Then, use
the "View" menu again to restore your favorite setting (I think, from your
message, that you're using large pictograms - I always have the details
view selected, but that's just personal preference).
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

A simple INSERT Problem

Dev Tool: VB6
Server: SQL Server 2000.
Environment: Windows 2000/Windows XP/Windows 2000 Server
I have changed a user connectivity from WINDOWS NT trusted connection to
SQL Server Authentication.
I have granted the same permissions to the new user.
The problem is as follows:
The new user cannot execute stored procedures which contains INSERT staments.
Having the same connection and user id. When I execute the stored procedure
in the Query Analyzer console I have no problem, but when I execute it in a
Visual Basic 6.0 Application, using ADO, I get the following message:
"Operation is not Allowed when the Object is closed."
Note: I created the table, so I'm the owner, I should have no problems(??)
What are the permission differences between Windows NT Trusted Connection
and SQL Server Authentication?
Rick
Try stepping through the debugger and check to see if the connection is open.
"Rick" wrote:

> Dev Tool: VB6
> Server: SQL Server 2000.
> Environment: Windows 2000/Windows XP/Windows 2000 Server
> I have changed a user connectivity from WINDOWS NT trusted connection to
> SQL Server Authentication.
> I have granted the same permissions to the new user.
> The problem is as follows:
> The new user cannot execute stored procedures which contains INSERT staments.
> Having the same connection and user id. When I execute the stored procedure
> in the Query Analyzer console I have no problem, but when I execute it in a
> Visual Basic 6.0 Application, using ADO, I get the following message:
> "Operation is not Allowed when the Object is closed."
> Note: I created the table, so I'm the owner, I should have no problems(??)
> What are the permission differences between Windows NT Trusted Connection
> and SQL Server Authentication?
>
> --
> Rick
|||Actually the stored proc is excuted and INSERT statement is done.
the problem is the message:
"Operation is not Allowed when the Object is closed."
This is the store proc:
CREATE PROCEDURE PROC_TEST
AS
INSERT INTO TEST
(TEST, DATE )
VALUES
('Value', GETDATE())
select * from TEST
RETURN
This is the call in Visual Basic 6.0:
strSQL = "EXECUTE PROC_TEST "
strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
ctlADO.CommandType = adCmdText
ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
ctlADO.CursorLocation = adUseClient
ctlADO.ConnectionString = strCnn
ctlADO.RecordSource = strSQL
ctlADO.Refresh
Notice that ctlADO is an ADODC control.
Rick
|||Add SET NOCOUNT ON in the beginning of your proc code. The "rows affected" from your INSERT message
is treaded as a recordset by classic ADO.
You can also do a .NextRecordset to navigate past the dummy recordset from the INSERT, but I don't
recommend that.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:31547951-D174-49FB-B21A-50F44E65DB61@.microsoft.com...
> Actually the stored proc is excuted and INSERT statement is done.
> the problem is the message:
> "Operation is not Allowed when the Object is closed."
> This is the store proc:
> CREATE PROCEDURE PROC_TEST
> AS
> INSERT INTO TEST
> (TEST, DATE )
> VALUES
> ('Value', GETDATE())
> select * from TEST
> RETURN
> This is the call in Visual Basic 6.0:
> strSQL = "EXECUTE PROC_TEST "
> strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
> Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
> ctlADO.CommandType = adCmdText
> ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
> ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
> ctlADO.CursorLocation = adUseClient
> ctlADO.ConnectionString = strCnn
> ctlADO.RecordSource = strSQL
> ctlADO.Refresh
>
> Notice that ctlADO is an ADODC control.
> --
> Rick
|||Using ADODC control (and Data Environment) is a very bad choice. Very few
exerienced VB programmer uses it, although most VB books for newbies have an
example to show how easy in VB to deal with database. Avoid it whenever
possible, especially in your situation of simply sending ADODB Command to
SQL Server to execute SPs.
It is very simple do use an ADO Command object the execute SPs in SQL
Server.
Dim cn AS ADODB.Connection
Dim cmd AS ADODB.Command
Set cn=New ADODB.Connection
cn.Open myConnectionString
Set cmd=New ADODB.Command
cmd.CommandType=adStoredProc
cmd.CommandText="theStoredProcedureName"
Set cmd.ActiveConnection=cn
''Add ADODB Parameters here if the SP expects parameter
cmd.Execute 'You are done
cn.Close 'Close the connection
Note, you need add some error handling code, of course.
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:31547951-D174-49FB-B21A-50F44E65DB61@.microsoft.com...
> Actually the stored proc is excuted and INSERT statement is done.
> the problem is the message:
> "Operation is not Allowed when the Object is closed."
> This is the store proc:
> CREATE PROCEDURE PROC_TEST
> AS
> INSERT INTO TEST
> (TEST, DATE )
> VALUES
> ('Value', GETDATE())
> select * from TEST
> RETURN
> This is the call in Visual Basic 6.0:
> strSQL = "EXECUTE PROC_TEST "
> strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
> Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
> ctlADO.CommandType = adCmdText
> ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
> ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
> ctlADO.CursorLocation = adUseClient
> ctlADO.ConnectionString = strCnn
> ctlADO.RecordSource = strSQL
> ctlADO.Refresh
>
> Notice that ctlADO is an ADODC control.
> --
> Rick

A simple INSERT Problem

Dev Tool: VB6
Server: SQL Server 2000.
Environment: Windows 2000/Windows XP/Windows 2000 Server
I have changed a user connectivity from WINDOWS NT trusted connection to
SQL Server Authentication.
I have granted the same permissions to the new user.
The problem is as follows:
The new user cannot execute stored procedures which contains INSERT staments
.
Having the same connection and user id. When I execute the stored procedure
in the Query Analyzer console I have no problem, but when I execute it in a
Visual Basic 6.0 Application, using ADO, I get the following message:
"Operation is not Allowed when the Object is closed."
Note: I created the table, so I'm the owner, I should have no problems(??)
What are the permission differences between Windows NT Trusted Connection
and SQL Server Authentication?
RickTry stepping through the debugger and check to see if the connection is open
.
"Rick" wrote:

> Dev Tool: VB6
> Server: SQL Server 2000.
> Environment: Windows 2000/Windows XP/Windows 2000 Server
> I have changed a user connectivity from WINDOWS NT trusted connection to
> SQL Server Authentication.
> I have granted the same permissions to the new user.
> The problem is as follows:
> The new user cannot execute stored procedures which contains INSERT stamen
ts.
> Having the same connection and user id. When I execute the stored procedur
e
> in the Query Analyzer console I have no problem, but when I execute it in
a
> Visual Basic 6.0 Application, using ADO, I get the following message:
> "Operation is not Allowed when the Object is closed."
> Note: I created the table, so I'm the owner, I should have no problems(??
)
> What are the permission differences between Windows NT Trusted Connection
> and SQL Server Authentication?
>
> --
> Rick|||Actually the stored proc is excuted and INSERT statement is done.
the problem is the message:
"Operation is not Allowed when the Object is closed."
This is the store proc:
CREATE PROCEDURE PROC_TEST
AS
INSERT INTO TEST
(TEST, DATE )
VALUES
('Value', GETDATE())
select * from TEST
RETURN
This is the call in Visual Basic 6.0:
strSQL = "EXECUTE PROC_TEST "
strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
ctlADO.CommandType = adCmdText
ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
ctlADO.CursorLocation = adUseClient
ctlADO.ConnectionString = strCnn
ctlADO.RecordSource = strSQL
ctlADO.Refresh
Notice that ctlADO is an ADODC control.
--
Rick|||Add SET NOCOUNT ON in the beginning of your proc code. The "rows affected" f
rom your INSERT message
is treaded as a recordset by classic ADO.
You can also do a .NextRecordset to navigate past the dummy recordset from t
he INSERT, but I don't
recommend that.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:31547951-D174-49FB-B21A-50F44E65DB61@.microsoft.com...
> Actually the stored proc is excuted and INSERT statement is done.
> the problem is the message:
> "Operation is not Allowed when the Object is closed."
> This is the store proc:
> CREATE PROCEDURE PROC_TEST
> AS
> INSERT INTO TEST
> (TEST, DATE )
> VALUES
> ('Value', GETDATE())
> select * from TEST
> RETURN
> This is the call in Visual Basic 6.0:
> strSQL = "EXECUTE PROC_TEST "
> strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
> Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
> ctlADO.CommandType = adCmdText
> ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
> ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
> ctlADO.CursorLocation = adUseClient
> ctlADO.ConnectionString = strCnn
> ctlADO.RecordSource = strSQL
> ctlADO.Refresh
>
> Notice that ctlADO is an ADODC control.
> --
> Rick|||Using ADODC control (and Data Environment) is a very bad choice. Very few
exerienced VB programmer uses it, although most VB books for newbies have an
example to show how easy in VB to deal with database. Avoid it whenever
possible, especially in your situation of simply sending ADODB Command to
SQL Server to execute SPs.
It is very simple do use an ADO Command object the execute SPs in SQL
Server.
Dim cn AS ADODB.Connection
Dim cmd AS ADODB.Command
Set cn=New ADODB.Connection
cn.Open myConnectionString
Set cmd=New ADODB.Command
cmd.CommandType=adStoredProc
cmd.CommandText="theStoredProcedureName"
Set cmd.ActiveConnection=cn
''Add ADODB Parameters here if the SP expects parameter
cmd.Execute 'You are done
cn.Close 'Close the connection
Note, you need add some error handling code, of course.
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:31547951-D174-49FB-B21A-50F44E65DB61@.microsoft.com...
> Actually the stored proc is excuted and INSERT statement is done.
> the problem is the message:
> "Operation is not Allowed when the Object is closed."
> This is the store proc:
> CREATE PROCEDURE PROC_TEST
> AS
> INSERT INTO TEST
> (TEST, DATE )
> VALUES
> ('Value', GETDATE())
> select * from TEST
> RETURN
> This is the call in Visual Basic 6.0:
> strSQL = "EXECUTE PROC_TEST "
> strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
> Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
> ctlADO.CommandType = adCmdText
> ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
> ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
> ctlADO.CursorLocation = adUseClient
> ctlADO.ConnectionString = strCnn
> ctlADO.RecordSource = strSQL
> ctlADO.Refresh
>
> Notice that ctlADO is an ADODC control.
> --
> Rick

A simple INSERT Problem

Dev Tool: VB6
Server: SQL Server 2000.
Environment: Windows 2000/Windows XP/Windows 2000 Server
I have changed a user connectivity from WINDOWS NT trusted connection to
SQL Server Authentication.
I have granted the same permissions to the new user.
The problem is as follows:
The new user cannot execute stored procedures which contains INSERT staments.
Having the same connection and user id. When I execute the stored procedure
in the Query Analyzer console I have no problem, but when I execute it in a
Visual Basic 6.0 Application, using ADO, I get the following message:
"Operation is not Allowed when the Object is closed."
Note: I created the table, so I'm the owner, I should have no problems(¡?)
What are the permission differences between Windows NT Trusted Connection
and SQL Server Authentication?
--
RickTry stepping through the debugger and check to see if the connection is open.
"Rick" wrote:
> Dev Tool: VB6
> Server: SQL Server 2000.
> Environment: Windows 2000/Windows XP/Windows 2000 Server
> I have changed a user connectivity from WINDOWS NT trusted connection to
> SQL Server Authentication.
> I have granted the same permissions to the new user.
> The problem is as follows:
> The new user cannot execute stored procedures which contains INSERT staments.
> Having the same connection and user id. When I execute the stored procedure
> in the Query Analyzer console I have no problem, but when I execute it in a
> Visual Basic 6.0 Application, using ADO, I get the following message:
> "Operation is not Allowed when the Object is closed."
> Note: I created the table, so I'm the owner, I should have no problems(¡?)
> What are the permission differences between Windows NT Trusted Connection
> and SQL Server Authentication?
>
> --
> Rick|||Actually the stored proc is excuted and INSERT statement is done.
the problem is the message:
"Operation is not Allowed when the Object is closed."
This is the store proc:
CREATE PROCEDURE PROC_TEST
AS
INSERT INTO TEST
(TEST, DATE )
VALUES
('Value', GETDATE())
select * from TEST
RETURN
This is the call in Visual Basic 6.0:
strSQL = "EXECUTE PROC_TEST "
strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
ctlADO.CommandType = adCmdText
ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
ctlADO.CursorLocation = adUseClient
ctlADO.ConnectionString = strCnn
ctlADO.RecordSource = strSQL
ctlADO.Refresh
Notice that ctlADO is an ADODC control.
--
Rick|||Add SET NOCOUNT ON in the beginning of your proc code. The "rows affected" from your INSERT message
is treaded as a recordset by classic ADO.
You can also do a .NextRecordset to navigate past the dummy recordset from the INSERT, but I don't
recommend that.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:31547951-D174-49FB-B21A-50F44E65DB61@.microsoft.com...
> Actually the stored proc is excuted and INSERT statement is done.
> the problem is the message:
> "Operation is not Allowed when the Object is closed."
> This is the store proc:
> CREATE PROCEDURE PROC_TEST
> AS
> INSERT INTO TEST
> (TEST, DATE )
> VALUES
> ('Value', GETDATE())
> select * from TEST
> RETURN
> This is the call in Visual Basic 6.0:
> strSQL = "EXECUTE PROC_TEST "
> strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
> Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
> ctlADO.CommandType = adCmdText
> ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
> ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
> ctlADO.CursorLocation = adUseClient
> ctlADO.ConnectionString = strCnn
> ctlADO.RecordSource = strSQL
> ctlADO.Refresh
>
> Notice that ctlADO is an ADODC control.
> --
> Rick|||Using ADODC control (and Data Environment) is a very bad choice. Very few
exerienced VB programmer uses it, although most VB books for newbies have an
example to show how easy in VB to deal with database. Avoid it whenever
possible, especially in your situation of simply sending ADODB Command to
SQL Server to execute SPs.
It is very simple do use an ADO Command object the execute SPs in SQL
Server.
Dim cn AS ADODB.Connection
Dim cmd AS ADODB.Command
Set cn=New ADODB.Connection
cn.Open myConnectionString
Set cmd=New ADODB.Command
cmd.CommandType=adStoredProc
cmd.CommandText="theStoredProcedureName"
Set cmd.ActiveConnection=cn
''Add ADODB Parameters here if the SP expects parameter
cmd.Execute 'You are done
cn.Close 'Close the connection
Note, you need add some error handling code, of course.
"Rick" <Rick@.discussions.microsoft.com> wrote in message
news:31547951-D174-49FB-B21A-50F44E65DB61@.microsoft.com...
> Actually the stored proc is excuted and INSERT statement is done.
> the problem is the message:
> "Operation is not Allowed when the Object is closed."
> This is the store proc:
> CREATE PROCEDURE PROC_TEST
> AS
> INSERT INTO TEST
> (TEST, DATE )
> VALUES
> ('Value', GETDATE())
> select * from TEST
> RETURN
> This is the call in Visual Basic 6.0:
> strSQL = "EXECUTE PROC_TEST "
> strCnn = "Provider=SQLOLEDB;Persist Security Info=False;Initial
> Catalog=MyTable;Data Source=MyServe;User Id=MyName;Password=MyPassword;"
> ctlADO.CommandType = adCmdText
> ctlADO.ConnectionTimeout = cnConexionADO_p.ConnectionTimeout
> ctlADO.CommandTimeout = cnConexionADO_p.CommandTimeout
> ctlADO.CursorLocation = adUseClient
> ctlADO.ConnectionString = strCnn
> ctlADO.RecordSource = strSQL
> ctlADO.Refresh
>
> Notice that ctlADO is an ADODC control.
> --
> Rick

A problem with SQL Integrated Windows Logins

I am working with 3 SQL 2000 Machines. I manage them by assigning Windows 2000 groups as logins. All of this is fine except that on one server, I belong to a Windows group which gives me certain rights.
I log into my Windows 2000 machine using my domain account which is in the Windows group, When I go into Enterprise Manager I get a message "unable to access default database" and I can not log in. If I put my Windows account into the SQL logins everything is OK. No one else has this problem and I only have it on one server. Anyone?Check the domain account default database. Maybe the account does not have access rights for the default database. (if not then map the account to that DB,or change the default database for another one which have the appropriate rights).
When you log in using Enterprise Manager, SQL checks only the login permission not the access rights, that's why the connection is allowed.

Originally posted by courtjs
I am working with 3 SQL 2000 Machines. I manage them by assigning Windows 2000 groups as logins. All of this is fine except that on one server, I belong to a Windows group which gives me certain rights.
I log into my Windows 2000 machine using my domain account which is in the Windows group, When I go into Enterprise Manager I get a message "unable to access default database" and I can not log in. If I put my Windows account into the SQL logins everything is OK. No one else has this problem and I only have it on one server. Anyone?|||Check with SP_HELPLOGINS.

A problem with Microsoft SQL Server 2000 startup account

Hi,
I have a Microsoft Windows 2000 Advanced Server SP4 Active Directory machine
and another similar machine joined to the domain. On the other machine I have
Microsoft SQL Server 2000 SP3 set up and it uses the domain startup account
for both the main and the agent service. First time when I was changing the
startup account from local account to the domain account it had Domain Admins
privileges. When I then changed the group for the account to the Domain Users
the agent service suddenly became unable to log into the SQL Server using the
'sa' account - it was telling all the time that the login for the user 'sa'
failed, although I checked and rechecked the credentials and they were right.
What could have gone wrong here?
Many thanks,
Oskar
EM, right-click Agent, properties, right-most tab. Here you find the account agent uses. Make sure
this account exists in SQL Server with sysadmin privileges.
Also, search Books Online for below to read more about the service accounts:
"level token"
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:4705F64D-2678-4E1F-A7FF-922A331E1118@.microsoft.com...
> Hi,
> I have a Microsoft Windows 2000 Advanced Server SP4 Active Directory machine
> and another similar machine joined to the domain. On the other machine I have
> Microsoft SQL Server 2000 SP3 set up and it uses the domain startup account
> for both the main and the agent service. First time when I was changing the
> startup account from local account to the domain account it had Domain Admins
> privileges. When I then changed the group for the account to the Domain Users
> the agent service suddenly became unable to log into the SQL Server using the
> 'sa' account - it was telling all the time that the login for the user 'sa'
> failed, although I checked and rechecked the credentials and they were right.
> What could have gone wrong here?
> --
> Many thanks,
> Oskar
>

A problem with Microsoft SQL Server 2000 startup account

Hi,
I have a Microsoft Windows 2000 Advanced Server SP4 Active Directory machine
and another similar machine joined to the domain. On the other machine I have
Microsoft SQL Server 2000 SP3 set up and it uses the domain startup account
for both the main and the agent service. First time when I was changing the
startup account from local account to the domain account it had Domain Admins
privileges. When I then changed the group for the account to the Domain Users
the agent service suddenly became unable to log into the SQL Server using the
'sa' account - it was telling all the time that the login for the user 'sa'
failed, although I checked and rechecked the credentials and they were right.
What could have gone wrong here?
--
Many thanks,
OskarEM, right-click Agent, properties, right-most tab. Here you find the account agent uses. Make sure
this account exists in SQL Server with sysadmin privileges.
Also, search Books Online for below to read more about the service accounts:
"level token"
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:4705F64D-2678-4E1F-A7FF-922A331E1118@.microsoft.com...
> Hi,
> I have a Microsoft Windows 2000 Advanced Server SP4 Active Directory machine
> and another similar machine joined to the domain. On the other machine I have
> Microsoft SQL Server 2000 SP3 set up and it uses the domain startup account
> for both the main and the agent service. First time when I was changing the
> startup account from local account to the domain account it had Domain Admins
> privileges. When I then changed the group for the account to the Domain Users
> the agent service suddenly became unable to log into the SQL Server using the
> 'sa' account - it was telling all the time that the login for the user 'sa'
> failed, although I checked and rechecked the credentials and they were right.
> What could have gone wrong here?
> --
> Many thanks,
> Oskar
>

A problem with Microsoft SQL Server 2000 startup account

Hi,
I have a Microsoft Windows 2000 Advanced Server SP4 Active Directory machine
and another similar machine joined to the domain. On the other machine I hav
e
Microsoft SQL Server 2000 SP3 set up and it uses the domain startup account
for both the main and the agent service. First time when I was changing the
startup account from local account to the domain account it had Domain Admin
s
privileges. When I then changed the group for the account to the Domain User
s
the agent service suddenly became unable to log into the SQL Server using th
e
'sa' account - it was telling all the time that the login for the user 'sa'
failed, although I checked and rechecked the credentials and they were right
.
What could have gone wrong here?
Many thanks,
OskarEM, right-click Agent, properties, right-most tab. Here you find the account
agent uses. Make sure
this account exists in SQL Server with sysadmin privileges.
Also, search Books Online for below to read more about the service accounts:
"level token"
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:4705F64D-2678-4E1F-A7FF-922A331E1118@.microsoft.com...
> Hi,
> I have a Microsoft Windows 2000 Advanced Server SP4 Active Directory machi
ne
> and another similar machine joined to the domain. On the other machine I h
ave
> Microsoft SQL Server 2000 SP3 set up and it uses the domain startup accoun
t
> for both the main and the agent service. First time when I was changing th
e
> startup account from local account to the domain account it had Domain Adm
ins
> privileges. When I then changed the group for the account to the Domain Us
ers
> the agent service suddenly became unable to log into the SQL Server using
the
> 'sa' account - it was telling all the time that the login for the user 'sa
'
> failed, although I checked and rechecked the credentials and they were rig
ht.
> What could have gone wrong here?
> --
> Many thanks,
> Oskar
>

A Little Basic Help needed (SQLServer 2005) Merge Replication

Hi all,

We are using SQL Server 2005, on Windows server 2003 R2.

We Have Two Database Servers say DBServer1 and DBServer2, Now I wants to do Replication between these to servers, such that

1. The Changes at DBServer1 should be reflected at DBServer2
2. The Changes at DBServer2 should be reflected at DBServer1
3. Changes includes Data changes and Schema Changes
4. After every Synchronization Both Databases should be Identical

I tried doing so, what i did was
I cofigured Distribution at DBServer1, also Publisher and Publication at DBServer1
and Made a Subscription at DBServer2.

What I successfully done is
If Publisher means DBServer1 do some changes then it gets updated at DBServer2.
But New Rows added at DBServer2 doesn't gets added at DBServer1

Thanks in Advance,
Vishalgiri Goswami
Kalptaru Infosoft Pvt. Ltd.Did you start the merge agent job? The merge agent does the synchronization.|||Yes Sir, Merge Agent is Running, I have Sheduled it to Run at 5 min Interval, I am viewing it's status from View Synchronization Option.

Even My Snapshot Agent is running too.|||Did you define a subset filter clause? And did your subscriber even download the snapshot? The snapshot agent doesn't need to run every 5 minutes.|||DId your subscriber download the schema from the snapshot? Does your publication have filtering, if yes, what does the subset filtering clause look like?

A few simple questions about SQL Server 'Views'

Hello,
I am building an application for Windows Forms using. I am new to SQL
Server 'Views'. Are the following correct understanding of their use?
1.) I believe a view can be referenced in a stored procedure something
like this;
Select * from View1
Is that true?
2.) I believe I can update to a view even when it includes two tables.
I intend to build a dataAdapter to a view for select and update. I
believe it can keep track of how to perform the update? Do I understand
its use correctly?
3.) Is it necessary to include both the the PK and FK when two tables
are part of the view or does it know the relationship established in
the database in the 'diagrams' area take care of that?
Thank you,
dbuchanan1) Yes
2) As long as you update only one of the member tables. That said, some
views are not updateable.
3) No
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
<dbuchanan52@.hotmail.com> wrote in message
news:1132411200.326003.199900@.g49g2000cwa.googlegroups.com...
> Hello,
> I am building an application for Windows Forms using. I am new to SQL
> Server 'Views'. Are the following correct understanding of their use?
> 1.) I believe a view can be referenced in a stored procedure something
> like this;
> Select * from View1
> Is that true?
> 2.) I believe I can update to a view even when it includes two tables.
> I intend to build a dataAdapter to a view for select and update. I
> believe it can keep track of how to perform the update? Do I understand
> its use correctly?
> 3.) Is it necessary to include both the the PK and FK when two tables
> are part of the view or does it know the relationship established in
> the database in the 'diagrams' area take care of that?
> Thank you,
> dbuchanan
>|||dbuchanan52@.hotmail.com wrote:
> Hello,
> I am building an application for Windows Forms using. I am new to SQL
> Server 'Views'. Are the following correct understanding of their use?
> 1.) I believe a view can be referenced in a stored procedure something
> like this;
> Select * from View1
> Is that true?
Yes

> 2.) I believe I can update to a view even when it includes two tables.
> I intend to build a dataAdapter to a view for select and update. I
> believe it can keep track of how to perform the update? Do I understand
> its use correctly?
Copy&Pasted from SQLServer Documentation:
Updatable Views
You can modify the data of an underlying base table through a view, as
long as the following conditions are true:
Any modifications, including UPDATE, INSERT, and DELETE statements, must
reference columns from only one base table.
The columns being modified in the view must directly reference the
underlying data in the table columns. The columns cannot be derived in
any other way, such as through the following:
An aggregate function: AVG, COUNT, SUM, MIN, MAX, GROUPING, STDEV,
STDEVP, VAR, and VARP.
A computation. The column cannot be computed from an expression that
uses other columns. Columns that are formed by using the set operators
UNION, UNION ALL, CROSSJOIN, EXCEPT, and INTERSECT amount to a
computation and are also not updatable.
The columns being modified are not affected by GROUP BY, HAVING, or
DISTINCT clauses.
The previous restrictions apply to any subqueries in the FROM clause of
the view, just as they apply to the view itself. Generally, the Database
Engine must be able to unambiguously trace modifications from the view
definition to one base table. For more information, see Modifying Data
Through a View.
If the previous restrictions prevent you from modifying data directly
through a view, consider the following options:
INSTEAD OF Triggers
INSTEAD OF triggers can be created on a view to make a view updatable.
The INSTEAD OF trigger is executed instead of the data modification
statement on which the trigger is defined. This trigger lets the user
specify the set of actions that must happen to process the data
modification statement. Therefore, if an INSTEAD OF trigger exists for a
view on a specific data modification statement (INSERT, UPDATE, or
DELETE), the corresponding view is updatable through that statement. For
more information about INSTEAD OF triggers, see Designing INSTEAD OF
Triggers.
Partitioned Views
If the view is a partitioned view, the view is updatable, subject to
certain restrictions. When it is needed, the Database Engine
distinguishes local partitioned views as the views in which all
participating tables and the view are on the same instance of SQL
Server, and distributed partitioned views as the views in which at least
one of the tables in the view resides on a different or remote server.
For more information about partitioned views, see Creating Partitioned
Views.

> 3.) Is it necessary to include both the the PK and FK when two tables
> are part of the view or does it know the relationship established in
> the database in the 'diagrams' area take care of that?
You define Views in SQL... so you have to define the "join" that you
want to use.
> Thank you,
> dbuchanan
>

A few newbie questions on MSDE / Windows 2003 SBS

Hi!
I've installed a SBS 2K3 server, and everything seem to rock ok. If I not
misunderstood the whole concept, MSDE 2000 is shipped with the server OS, ok?
I've also installed Veritas BE ver. 9.1 Standard for SBS and the antivirus
software Panda Enerprise Secure. Both applications seem to register with SQL
ok, creating instances I can view by right-clicking the services icon to the
left of the system-time display.
But what if I need to create a database manually? I need to install a
dentist-application for my customer, and the installation-procedure doesn't
automatically register with sql. The database has to be moved to the new
server, and registered with sql FIRST.
What to do? Must my Customer by a full version of SQL server? Is it possible
to install SQL Server Standard Edition on a 2003 SBS ?
I would (as usual) be very grateful for any hints and tip's about this issue.
Regards
Tom Hagen
Tom,
I am not sure about registering the database manually with MSDE, as I am
still new to using it, but you can install SQL 2000 on SBS 2003. SBS2003
Premium comes with SQL Server anyway.
John
"Tom" wrote:

> Hi!
> I've installed a SBS 2K3 server, and everything seem to rock ok. If I not
> misunderstood the whole concept, MSDE 2000 is shipped with the server OS, ok?
> I've also installed Veritas BE ver. 9.1 Standard for SBS and the antivirus
> software Panda Enerprise Secure. Both applications seem to register with SQL
> ok, creating instances I can view by right-clicking the services icon to the
> left of the system-time display.
> But what if I need to create a database manually? I need to install a
> dentist-application for my customer, and the installation-procedure doesn't
> automatically register with sql. The database has to be moved to the new
> server, and registered with sql FIRST.
> What to do? Must my Customer by a full version of SQL server? Is it possible
> to install SQL Server Standard Edition on a 2003 SBS ?
> I would (as usual) be very grateful for any hints and tip's about this issue.
> Regards
> Tom Hagen
|||Hi, John!
I've managed to get some info on this issue (by MS themselves, actually).
You have to manually (by command-prompt), create an "instance" in MSDE. You
run MSDE setup with parameters (examples included in a htm-file in
installation folder).
Check out MSDE 2000 release A on:
http://www.microsoft.com/sql/msde/downloads/default.asp
I spoke to a swedish ms-consultant and he told me that installation of SQL
version 2000, 2003 or whatever is not possible on sbs 2k3 . MSDE 2000 is
tested by MS for one (1) default instance and fifteen (15) named instances.
So he and I and some programmers who developed the dental-application are
going
to give it a try.
Thanks, anyway!
Tom
"John Tkalcich" wrote:
[vbcol=seagreen]
> Tom,
> I am not sure about registering the database manually with MSDE, as I am
> still new to using it, but you can install SQL 2000 on SBS 2003. SBS2003
> Premium comes with SQL Server anyway.
> John
> "Tom" wrote:

A few database issues

A few questions:

1. What is better security wise: sql authentication or windows authentication?

2. If I use windows authentication, which account is normally used for access? and how do I set this in the database as well as the web.config?
(I test locally, but when I place the live site at my hosting provider I want to make sure that the windows account I used for testing is supported by them)

Thanks!

PS. SQL Server is driving me crazy with its no-helping-weird errors...(or is that just me? ;) )

1. If you run SQL Server on WinNT, Windows Authentication may be better. Windows Authentication is also called 'trusted connection', which means SQL trusts current Windows account context; SQL Server achieves login security integration with Windows NT 4.0 or Windows 2000 by using the security attributes of a network user to control login access.

SQL Server Authentication is provided for backward compatibility. When a user connects with a specified login name and password (both stored in SQL Server) from a nontrusted connection, SQL Server performs the authentication itself.

For more information, you can visit this website:http://msdn.microsoft.com/library/en-us/adminsql/ad_security_47u6.asp?frame=true

2. Current Windows logon account is used for Windows Authenticatoin (if the machine is in a domain, some delegation may be performed by the domain controller). Local 'Administrator' account on the machine is mapped to 'BUILTIN\Administrators' login in SQL Server; and if you want to connect to a remote SQL Server with Windows Authentication, you have to add the Windows account to the SQL Server logins (use Enterprise Manager->'Security'->'Logins').

In a VS2005 starter kit web application there is something like this in web.config that looks like using Window Authentication (in green):

<connectionStrings>
<add name="LocalSqlServer" connectionString="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|aspnetdb.mdf" />
</connectionStrings>

BTW, SQL Books Online provides some useful helping message, and more can be found inhttp://msdn.microsoft.com ^_^