A different question about SQL Server Access Denied

I have 2 development servers, both of which I need to use to run an ASP.NET app. The app connects to an external SQL Server with SQL Server authentication only. One of my servers connects properly, but the same exact app running on the second server generates the dreaded SQL Server Access Denied message. A traditional .asp file running on the second server does connect successfully to the database, so I have deduced that the problem is related either to the ASPNET account on the second server, or else to the structure of the server itself or IIS.

I have verified on both machines that IIS uses the ASPNET account for anonymous access. The only difference I can find is that the working server is using NTFS (and the VS_Developers account has full permission on my application's directory), while the problem server is using FAT. Does anyone know if it the FAT file system could be my problem? If so, should I convert to NTFS, or is there another solution? What else could I look at on the problem server? Any help would be greatly appreciated. Thanks.If you are using SQL Server authentication then using IIS anonymous accounts and ASP.Net accounts are not involved in the authentication. What is the exact message that appears? Login failed for user [...] ?

If you are using SQL server with SQL server authentication then in the connection string you should be providing the UID and Password of a SQL Server Login and there should be no "integrated security" clause in the connection string.|||Thanks for the reply. The error message is: "SQL Server does not exist or access is denied". There is no login failure error occurring.

Here is my connection string:
"Data Source=mySQLIPhere,1433;Network Library=DBMSSOCN;Initial Catalog=myDBName;User ID=mySQLUser;Password=mySQLPw;"

As I mentioned, this connection string works fine from one of the 2 development servers as well as from the production web server, so I don't think the connection string is the problem.|||Seems ok to me; if you are willing to do some experiments try these in order.

Verify that you can access mySQLIPhere machine from the machine causing the problem. e.g. by trying to open \\mySQLIPhere or by pinging.

Use query analyzer to connect to SQL Server from the machine causing problem. In "connect to SQL Server" dialog box provide mySQLIPhere as Sql Server name, select Sql Sever Auth, loginname and password. If this works you may experiment rewriting your connection string bit by bit e.g.:
"Data Source=mySQLIPhere; User ID=mySQLUser; Password=mySQLPw;"
"Data Source=mySQLIPhere,1433; User ID=mySQLUser; Password=mySQLPw;"
"Data Source=mySQLIPhere;Initial Catalog=myDBName; User ID=mySQLUser; Password=mySQLPw;"

It is most probably the SQL Server not exist (not found) part that looks true, rather than the access denied part.

8updating a sql servi stored procedures/triggers

hi all,
we have two servers. we have an oracle 8i and a sql 2000 server.
is it possible to write stored procedures or triggers in oracle 8i that will create, update and delete records in sql server.if so what are the steps to do so and an example of a trigger/stored procedure. i have seen many ways to connect two oracle or two sql servers. i also see ways to link the servers but what we are trying to do is when something commits in the the oracle database that it will also do the same in the sql server. keep in mind out table structures are different due to security rights on the sql server that is why the some fields will not move over. also what is the best method to do this? i also see using vb uding ado rdo. i see ole db and odbc connections between the two, and i see some third party software. any help is much appreciaedI would think that your best bet would be to accomplish this task using an application front end and not trying to do it through a trigger or stored proc on Oracle. But that's probably because I'm more of a developer than a DBA (tho' I'm working on the latter).

Using ADO, you can use BeginTrans and CommitTrans to ensure that a transaction completes on SQL before committing the transaction on Oracle. Set checks for errors and use RollbackTrans on both connections to "undo" everything if a problem occurs.

That said, what really matters is your requirement; are these transactions user-initiated or are they meant to be a part of an automated extract? Though each can be handled by ADO, you would handle each situation a little differently.

Regards,

Hugh Scott

Originally posted by rdavidoff
hi all,
we have two servers. we have an oracle 8i and a sql 2000 server.
is it possible to write stored procedures or triggers in oracle 8i that will create, update and delete records in sql server.if so what are the steps to do so and an example of a trigger/stored procedure. i have seen many ways to connect two oracle or two sql servers. i also see ways to link the servers but what we are trying to do is when something commits in the the oracle database that it will also do the same in the sql server. keep in mind out table structures are different due to security rights on the sql server that is why the some fields will not move over. also what is the best method to do this? i also see using vb uding ado rdo. i see ole db and odbc connections between the two, and i see some third party software. any help is much appreciaed|||thanks for your suggestion,
here is the business process that will give you a better understanding of our problem. see a sql server was purchased becuase a web developer is gong to do web based reports using tables from sql server 2000. the problem is that the company has a legacy 8.04 oracle dtabase that has been installed for years. the web developer wants to use and convinced hi people he wants to use sql server 2000. our job is to come up with a process to make the sql server data be as real time as possible to the oracle database b/c everything is really getting stored there. so whether it be by triggers, stored procedures, or some front end using either ado, ole db, odbc, or whatever api thats out there.
do you have some sort of sample of an ado instance. all out transactions will be user initiated and committed on the oracle side
thanks again,
robert

Originally posted by hmscott
I would think that your best bet would be to accomplish this task using an application front end and not trying to do it through a trigger or stored proc on Oracle. But that's probably because I'm more of a developer than a DBA (tho' I'm working on the latter).

Using ADO, you can use BeginTrans and CommitTrans to ensure that a transaction completes on SQL before committing the transaction on Oracle. Set checks for errors and use RollbackTrans on both connections to "undo" everything if a problem occurs.

That said, what really matters is your requirement; are these transactions user-initiated or are they meant to be a part of an automated extract? Though each can be handled by ADO, you would handle each situation a little differently.

Regards,

Hugh Scott|||Ewww, yuck. I realize decisions have already been made, but there's really nothing wrong with developing web apps using Oracle. I prefer SQL, but that's a different story.

We're doing something that might be considered a bit similar, but it is by no means "realtime". We have a production AS/400. Every fifteen minutes we siphon off selected data to a SQL server. We then use the SQL server to display the data on the web. The customer accepts the fifteen minute delay as a penalty. A side benefit is that the load on the AS/400 is regular and predictable while the customer can run queries to his heart's delight (and they delight in it a lot!) on the SQL server.

To pull the data from Oracle to SQL we use DTS packages that are scheduled on the SQL server.

Option 1
Do you control (own the source code) the application that stores the data on the Oracle Server?

If the answer is "yes", then you have a lot of rewriting to do to make updates to both databases, but it is potentially doable and "real time". Whether the re-write is justifiable is another matter for management to decide.

Option b
A possible alternative is to use a Linked Server (establish the Oracle Server as a linked server on SQL). You can then write distributed Queries that access the Oracle data directly. CAUTION: my experience with distributed queries is not stellar. The more complex they are, the longer they take to run. See SQL Books On Line for more information on Distributed Queries and Linked Servers.

Option iii
Use DTS packages to pull the data into SQL on a scheduled basis. This is doable (we are doing it now) but it requires a LOT of thought into what data is going to be brought across and consideration must be given to the state of the data (ie, open orders versus closed orders, etc).

Option Other
Maybe there is a way to do this in Oracle using triggers or stored procedures. You might even look into replication (now there's an idea!), but I have no idea how to go about setting it up.

Or you could simply find a web developer willing to work with Oracle!!!

Sorry, I hope one of these helps!

Regards,

Hugh Scott

Originally posted by rdavidoff
thanks for your suggestion,
here is the business process that will give you a better understanding of our problem. see a sql server was purchased becuase a web developer is gong to do web based reports using tables from sql server 2000. the problem is that the company has a legacy 8.04 oracle dtabase that has been installed for years. the web developer wants to use and convinced hi people he wants to use sql server 2000. our job is to come up with a process to make the sql server data be as real time as possible to the oracle database b/c everything is really getting stored there. so whether it be by triggers, stored procedures, or some front end using either ado, ole db, odbc, or whatever api thats out there.
do you have some sort of sample of an ado instance. all out transactions will be user initiated and committed on the oracle side
thanks again,
robert|||Originally posted by hmscott

We're doing something that might be considered a bit similar, but it is by no means "realtime". We have a production AS/400. Every fifteen minutes we siphon off selected data to a SQL server. We then use the SQL server to display the data on the web. The customer accepts the fifteen minute delay as a penalty. A side benefit is that the load on the AS/400 is regular and predictable while the customer can run queries to his heart's delight (and they delight in it a lot!) on the SQL server.



I am atempting this very thing. Only difference is it is not Oracle it is a remote Turbo Image Database (ISAM files).

I have a stored procedure written that does a set of queries using OPENQUERY and updates three tables. My plan is to run it once every 10 - 15 minutes or so.

My stumbling block is that the job I scheduled to run the stored procedure is failing, but once I get that worked out it should be fine. I have talked to the owners of the data (it is a registration database for a community college) and the delay is acceptable in this situation.

So, if the data is not life threatining if there is a delay, I'd say that this is your best bet.|||i was reading ur option iii and it really doesn't sound that bad. thanks again for all the advice 15 minutes delayed is still good enough for what we intend to use this data for. after allwe are not a brokerage company that needs streaming real time data. do you have any information or advise pn dts packages and where may i look into this further.
thanks again
Bob

Originally posted by hmscott
Ewww, yuck. I realize decisions have already been made, but there's really nothing wrong with developing web apps using Oracle. I prefer SQL, but that's a different story.

We're doing something that might be considered a bit similar, but it is by no means "realtime". We have a production AS/400. Every fifteen minutes we siphon off selected data to a SQL server. We then use the SQL server to display the data on the web. The customer accepts the fifteen minute delay as a penalty. A side benefit is that the load on the AS/400 is regular and predictable while the customer can run queries to his heart's delight (and they delight in it a lot!) on the SQL server.

To pull the data from Oracle to SQL we use DTS packages that are scheduled on the SQL server.

Option 1
Do you control (own the source code) the application that stores the data on the Oracle Server?

If the answer is "yes", then you have a lot of rewriting to do to make updates to both databases, but it is potentially doable and "real time". Whether the re-write is justifiable is another matter for management to decide.

Option b
A possible alternative is to use a Linked Server (establish the Oracle Server as a linked server on SQL). You can then write distributed Queries that access the Oracle data directly. CAUTION: my experience with distributed queries is not stellar. The more complex they are, the longer they take to run. See SQL Books On Line for more information on Distributed Queries and Linked Servers.

Option iii
Use DTS packages to pull the data into SQL on a scheduled basis. This is doable (we are doing it now) but it requires a LOT of thought into what data is going to be brought across and consideration must be given to the state of the data (ie, open orders versus closed orders, etc).

Option Other
Maybe there is a way to do this in Oracle using triggers or stored procedures. You might even look into replication (now there's an idea!), but I have no idea how to go about setting it up.

Or you could simply find a web developer willing to work with Oracle!!!

Sorry, I hope one of these helps!

Regards,

Hugh Scott|||Some gotcha's that you may want to consider and a site that is well worth looking at:

1. Data Transformation Services (DTS) are essentially mini-programs that are created in a GUI environment. As such, there is a LOT of complexity that is hidden from you. As you can imagine, there are both strong points and weak points to this:

a. Strong point: they are fairly easy to create and work with
b. Strong point: there are a lot of objects to work with and that makes just about any task doable.
c. Weak point: they are sometimes difficult to manage unless you spend a lot of time learning how to use dynamic properties that can be stored on the server
d. Weak point: since it's easy for a novice to work with these, it's easy to make a novice mistake and mess up a bunch of things

2. DTS runs in a separate memory space from the SQL server application. I have recently experienced some very negative side effects from having too many DTS packages running simultaneously. If it is at all possible, consider running DTS on a separate server from the database server.

3. This is a hard one for people new to DTS to understand. DTS always runs in the context of the client machine on which you are viewing the DTS package. Even though you are in Enterprise Manager and you THINK you are executing the DTS package on the SQL server, it is actually running using the DLL context of your client workstation. Send me an e-mail and I'll explain this one further. It's an important concept and not very well explained (in my opinion) in SQL BOL.

4. I have had a VERY bad experience with Meta Data Services. I would recommend avoiding this feature in SQL Server in a production environment.

5. Be sure that your client workstation and the SQL Server where the packages are stored are running the SAME version of SQL Server (same SP, too). DTS pacakges can be migrated from older versions to newer versions, but they are not necessarily backward compatible. DTS pacakges in SQL 7.0 were pretty bad until around SP3.

66. A good website to check out is www.sqldts.com. I found a really great tool for backing up DTS pacakges on there.

Good luck,

Hugh Scott
Originally posted by rdavidoff
i was reading ur option iii and it really doesn't sound that bad. thanks again for all the advice 15 minutes delayed is still good enough for what we intend to use this data for. after allwe are not a brokerage company that needs streaming real time data. do you have any information or advise pn dts packages and where may i look into this further.
thanks again
Bob

837 patch and MS03-031

Hello
We're about to apply the MS03-031 security rollup patch to upgrade our 90
SQL Servers from SP3a (760) to (818).
Problem is we have applied a hotfix already to a couple of boxes which
ugraded SQL to version (837).
What will happen when we apply MS03-031 to these boxes with the hotfix? Will
it fail and if so whats the solution?
thank you
-- cranfield, DBA
Hi
It will run, but is clever enough not to run older scripts against the newer
build. It does binary file version checking so it won't overwrite newer
binaries.
Have you considered hotfix 878?
When I tried to run 818 against a 952 server, I got the following:
=== Version check on sqlservr.exe 8.0.952 shows different major build of
sqlservr.exe than hotfix build number 8.00.818
=== NOT RUNNING SCRIPTS
The build number of SQLSERVR.EXE and HotFix package did not match. This
happens
when SQLSERVR.EXE was not replaced because the version was higher than the
Hotfix build.
In these cases Hotfix will not run any scripts and return error code
ERROR_BAD_ENVIRONMENT
Error message: Error running SQL script. Please view the log file for details.
INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVER,
the error code returned was: 10
<EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
Regards
Mike
"cranfield" wrote:

> Hello
> We're about to apply the MS03-031 security rollup patch to upgrade our 90
> SQL Servers from SP3a (760) to (818).
> Problem is we have applied a hotfix already to a couple of boxes which
> ugraded SQL to version (837).
> What will happen when we apply MS03-031 to these boxes with the hotfix? Will
> it fail and if so whats the solution?
> thank you
> -- cranfield, DBA
|||Hi Mike
Why do you ask if I have considered hotfix 878? We applied the 837 hotfix i
an attempt to sort out some Exception errors we were having on our 4-node
cluster.
We're just looking at bringing up our servers to an accepted level and our
testers have only tested up to 818, MS02-031.
regards
Alan Cranfield
DBA Support
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> It will run, but is clever enough not to run older scripts against the newer
> build. It does binary file version checking so it won't overwrite newer
> binaries.
> Have you considered hotfix 878?
> When I tried to run 818 against a 952 server, I got the following:
> === Version check on sqlservr.exe 8.0.952 shows different major build of
> sqlservr.exe than hotfix build number 8.00.818
>
> === NOT RUNNING SCRIPTS
> The build number of SQLSERVR.EXE and HotFix package did not match. This
> happens
> when SQLSERVR.EXE was not replaced because the version was higher than the
> Hotfix build.
> In these cases Hotfix will not run any scripts and return error code
> ERROR_BAD_ENVIRONMENT
> Error message: Error running SQL script. Please view the log file for details.
> INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVER,
> the error code returned was: 10
> <EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
> Regards
> Mike
> "cranfield" wrote:
|||Hi
878 is the highest publicly available hotfix, that is fully supported by PSS.
We encountered quite a few problems with hotfixes in the 820 to 850 range,
and those issues were fixed after 850.
(regression bugs etc)
Regards
Mike
"Cranfield" wrote:
[vbcol=seagreen]
> Hi Mike
> Why do you ask if I have considered hotfix 878? We applied the 837 hotfix i
> an attempt to sort out some Exception errors we were having on our 4-node
> cluster.
> We're just looking at bringing up our servers to an accepted level and our
> testers have only tested up to 818, MS02-031.
> regards
> Alan Cranfield
> DBA Support
> "Mike Epprecht (SQL MVP)" wrote:
|||I suspect applying MS03-031 to the servers that are already at
8.00.837 will do nothing - it shouldn't overwrite files with
earlier versions, and you can compare the file information in the KB
article http://support.microsoft.com/kb/821277 with what's on your
servers.
Is there a reason you think MS03-31 contains something that is
not already installed as part of the 837 hotfix on the hotfixed boxes?
Usually these things are cumulative, and especially since 818 was a
security issue, I'd be surprised if MSFT gave out something numbered
8.00.837 that didn't fix prior security issues.
Steve Kass
Drew University
cranfield wrote:

>Hello
>We're about to apply the MS03-031 security rollup patch to upgrade our 90
>SQL Servers from SP3a (760) to (818).
>Problem is we have applied a hotfix already to a couple of boxes which
>ugraded SQL to version (837).
>What will happen when we apply MS03-031 to these boxes with the hotfix? Will
>it fail and if so whats the solution?
>thank you
>-- cranfield, DBA
>
|||This is exactly what i want to know. Can I safely assume that I don't have to
patch the 837 servers as they will already be up to 818 level?
thanks
alan
"Steve Kass" wrote:

> I suspect applying MS03-031 to the servers that are already at
> 8.00.837 will do nothing - it shouldn't overwrite files with
> earlier versions, and you can compare the file information in the KB
> article http://support.microsoft.com/kb/821277 with what's on your
> servers.
> Is there a reason you think MS03-31 contains something that is
> not already installed as part of the 837 hotfix on the hotfixed boxes?
> Usually these things are cumulative, and especially since 818 was a
> security issue, I'd be surprised if MSFT gave out something numbered
> 8.00.837 that didn't fix prior security issues.
> Steve Kass
> Drew University
> cranfield wrote:
>

837 patch and MS03-031

Hello
We're about to apply the MS03-031 security rollup patch to upgrade our 90
SQL Servers from SP3a (760) to (818).
Problem is we have applied a hotfix already to a couple of boxes which
ugraded SQL to version (837).
What will happen when we apply MS03-031 to these boxes with the hotfix? Will
it fail and if so whats the solution?
thank you
-- cranfield, DBAHi
It will run, but is clever enough not to run older scripts against the newer
build. It does binary file version checking so it won't overwrite newer
binaries.
Have you considered hotfix 878?
When I tried to run 818 against a 952 server, I got the following:
=== Version check on sqlservr.exe 8.0.952 shows different major build of
sqlservr.exe than hotfix build number 8.00.818
=== NOT RUNNING SCRIPTS
The build number of SQLSERVR.EXE and HotFix package did not match. This
happens
when SQLSERVR.EXE was not replaced because the version was higher than the
Hotfix build.
In these cases Hotfix will not run any scripts and return error code
ERROR_BAD_ENVIRONMENT
Error message: Error running SQL script. Please view the log file for detail
s.
INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVER,
the error code returned was: 10
<EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
Regards
Mike
"cranfield" wrote:

> Hello
> We're about to apply the MS03-031 security rollup patch to upgrade our 90
> SQL Servers from SP3a (760) to (818).
> Problem is we have applied a hotfix already to a couple of boxes which
> ugraded SQL to version (837).
> What will happen when we apply MS03-031 to these boxes with the hotfix? Wi
ll
> it fail and if so whats the solution?
> thank you
> -- cranfield, DBA|||Hi Mike
Why do you ask if I have considered hotfix 878? We applied the 837 hotfix i
an attempt to sort out some Exception errors we were having on our 4-node
cluster.
We're just looking at bringing up our servers to an accepted level and our
testers have only tested up to 818, MS02-031.
regards
Alan Cranfield
DBA Support
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> It will run, but is clever enough not to run older scripts against the new
er
> build. It does binary file version checking so it won't overwrite newer
> binaries.
> Have you considered hotfix 878?
> When I tried to run 818 against a 952 server, I got the following:
> === Version check on sqlservr.exe 8.0.952 shows different major build of
> sqlservr.exe than hotfix build number 8.00.818
>
> === NOT RUNNING SCRIPTS
> The build number of SQLSERVR.EXE and HotFix package did not match. This
> happens
> when SQLSERVR.EXE was not replaced because the version was higher than the
> Hotfix build.
> In these cases Hotfix will not run any scripts and return error code
> ERROR_BAD_ENVIRONMENT
> Error message: Error running SQL script. Please view the log file for deta
ils.
> INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVE
R,
> the error code returned was: 10
> <EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
> Regards
> Mike
> "cranfield" wrote:
>|||Hi
878 is the highest publicly available hotfix, that is fully supported by PSS
.
We encountered quite a few problems with hotfixes in the 820 to 850 range,
and those issues were fixed after 850.
(regression bugs etc)
Regards
Mike
"Cranfield" wrote:
[vbcol=seagreen]
> Hi Mike
> Why do you ask if I have considered hotfix 878? We applied the 837 hotfix
i
> an attempt to sort out some Exception errors we were having on our 4-node
> cluster.
> We're just looking at bringing up our servers to an accepted level and our
> testers have only tested up to 818, MS02-031.
> regards
> Alan Cranfield
> DBA Support
> "Mike Epprecht (SQL MVP)" wrote:
>|||I suspect applying MS03-031 to the servers that are already at
8.00.837 will do nothing - it shouldn't overwrite files with
earlier versions, and you can compare the file information in the KB
article http://support.microsoft.com/kb/821277 with what's on your
servers.
Is there a reason you think MS03-31 contains something that is
not already installed as part of the 837 hotfix on the hotfixed boxes?
Usually these things are cumulative, and especially since 818 was a
security issue, I'd be surprised if MSFT gave out something numbered
8.00.837 that didn't fix prior security issues.
Steve Kass
Drew University
cranfield wrote:

>Hello
>We're about to apply the MS03-031 security rollup patch to upgrade our 90
>SQL Servers from SP3a (760) to (818).
>Problem is we have applied a hotfix already to a couple of boxes which
>ugraded SQL to version (837).
>What will happen when we apply MS03-031 to these boxes with the hotfix? Wil
l
>it fail and if so whats the solution?
>thank you
>-- cranfield, DBA
>|||This is exactly what i want to know. Can I safely assume that I don't have t
o
patch the 837 servers as they will already be up to 818 level?
thanks
alan
"Steve Kass" wrote:

> I suspect applying MS03-031 to the servers that are already at
> 8.00.837 will do nothing - it shouldn't overwrite files with
> earlier versions, and you can compare the file information in the KB
> article http://support.microsoft.com/kb/821277 with what's on your
> servers.
> Is there a reason you think MS03-31 contains something that is
> not already installed as part of the 837 hotfix on the hotfixed boxes?
> Usually these things are cumulative, and especially since 818 was a
> security issue, I'd be surprised if MSFT gave out something numbered
> 8.00.837 that didn't fix prior security issues.
> Steve Kass
> Drew University
> cranfield wrote:
>
>

837 patch and MS03-031

Hello
We're about to apply the MS03-031 security rollup patch to upgrade our 90
SQL Servers from SP3a (760) to (818).
Problem is we have applied a hotfix already to a couple of boxes which
ugraded SQL to version (837).
What will happen when we apply MS03-031 to these boxes with the hotfix? Will
it fail and if so whats the solution?
thank you
-- cranfield, DBAHi
It will run, but is clever enough not to run older scripts against the newer
build. It does binary file version checking so it won't overwrite newer
binaries.
Have you considered hotfix 878?
When I tried to run 818 against a 952 server, I got the following:
=== Version check on sqlservr.exe 8.0.952 shows different major build of
sqlservr.exe than hotfix build number 8.00.818
=== NOT RUNNING SCRIPTS
The build number of SQLSERVR.EXE and HotFix package did not match. This
happens
when SQLSERVR.EXE was not replaced because the version was higher than the
Hotfix build.
In these cases Hotfix will not run any scripts and return error code
ERROR_BAD_ENVIRONMENT
Error message: Error running SQL script. Please view the log file for details.
INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVER,
the error code returned was: 10
<EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
Regards
Mike
"cranfield" wrote:
> Hello
> We're about to apply the MS03-031 security rollup patch to upgrade our 90
> SQL Servers from SP3a (760) to (818).
> Problem is we have applied a hotfix already to a couple of boxes which
> ugraded SQL to version (837).
> What will happen when we apply MS03-031 to these boxes with the hotfix? Will
> it fail and if so whats the solution?
> thank you
> -- cranfield, DBA|||Hi Mike
Why do you ask if I have considered hotfix 878? We applied the 837 hotfix i
an attempt to sort out some Exception errors we were having on our 4-node
cluster.
We're just looking at bringing up our servers to an accepted level and our
testers have only tested up to 818, MS02-031.
regards
Alan Cranfield
DBA Support
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> It will run, but is clever enough not to run older scripts against the newer
> build. It does binary file version checking so it won't overwrite newer
> binaries.
> Have you considered hotfix 878?
> When I tried to run 818 against a 952 server, I got the following:
> === Version check on sqlservr.exe 8.0.952 shows different major build of
> sqlservr.exe than hotfix build number 8.00.818
>
> === NOT RUNNING SCRIPTS
> The build number of SQLSERVR.EXE and HotFix package did not match. This
> happens
> when SQLSERVR.EXE was not replaced because the version was higher than the
> Hotfix build.
> In these cases Hotfix will not run any scripts and return error code
> ERROR_BAD_ENVIRONMENT
> Error message: Error running SQL script. Please view the log file for details.
> INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVER,
> the error code returned was: 10
> <EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
> Regards
> Mike
> "cranfield" wrote:
> > Hello
> >
> > We're about to apply the MS03-031 security rollup patch to upgrade our 90
> > SQL Servers from SP3a (760) to (818).
> >
> > Problem is we have applied a hotfix already to a couple of boxes which
> > ugraded SQL to version (837).
> >
> > What will happen when we apply MS03-031 to these boxes with the hotfix? Will
> > it fail and if so whats the solution?
> >
> > thank you
> >
> > -- cranfield, DBA|||Hi
878 is the highest publicly available hotfix, that is fully supported by PSS.
We encountered quite a few problems with hotfixes in the 820 to 850 range,
and those issues were fixed after 850.
(regression bugs etc)
Regards
Mike
"Cranfield" wrote:
> Hi Mike
> Why do you ask if I have considered hotfix 878? We applied the 837 hotfix i
> an attempt to sort out some Exception errors we were having on our 4-node
> cluster.
> We're just looking at bringing up our servers to an accepted level and our
> testers have only tested up to 818, MS02-031.
> regards
> Alan Cranfield
> DBA Support
> "Mike Epprecht (SQL MVP)" wrote:
> > Hi
> >
> > It will run, but is clever enough not to run older scripts against the newer
> > build. It does binary file version checking so it won't overwrite newer
> > binaries.
> >
> > Have you considered hotfix 878?
> >
> > When I tried to run 818 against a 952 server, I got the following:
> >
> > === Version check on sqlservr.exe 8.0.952 shows different major build of
> > sqlservr.exe than hotfix build number 8.00.818
> >
> >
> > === NOT RUNNING SCRIPTS
> > The build number of SQLSERVR.EXE and HotFix package did not match. This
> > happens
> > when SQLSERVR.EXE was not replaced because the version was higher than the
> > Hotfix build.
> > In these cases Hotfix will not run any scripts and return error code
> > ERROR_BAD_ENVIRONMENT
> >
> > Error message: Error running SQL script. Please view the log file for details.
> > INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVER,
> > the error code returned was: 10
> > <EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
> >
> > Regards
> > Mike
> >
> > "cranfield" wrote:
> >
> > > Hello
> > >
> > > We're about to apply the MS03-031 security rollup patch to upgrade our 90
> > > SQL Servers from SP3a (760) to (818).
> > >
> > > Problem is we have applied a hotfix already to a couple of boxes which
> > > ugraded SQL to version (837).
> > >
> > > What will happen when we apply MS03-031 to these boxes with the hotfix? Will
> > > it fail and if so whats the solution?
> > >
> > > thank you
> > >
> > > -- cranfield, DBA|||I suspect applying MS03-031 to the servers that are already at
8.00.837 will do nothing - it shouldn't overwrite files with
earlier versions, and you can compare the file information in the KB
article http://support.microsoft.com/kb/821277 with what's on your
servers.
Is there a reason you think MS03-31 contains something that is
not already installed as part of the 837 hotfix on the hotfixed boxes?
Usually these things are cumulative, and especially since 818 was a
security issue, I'd be surprised if MSFT gave out something numbered
8.00.837 that didn't fix prior security issues.
Steve Kass
Drew University
cranfield wrote:
>Hello
>We're about to apply the MS03-031 security rollup patch to upgrade our 90
>SQL Servers from SP3a (760) to (818).
>Problem is we have applied a hotfix already to a couple of boxes which
>ugraded SQL to version (837).
>What will happen when we apply MS03-031 to these boxes with the hotfix? Will
>it fail and if so whats the solution?
>thank you
>-- cranfield, DBA
>|||This is exactly what i want to know. Can I safely assume that I don't have to
patch the 837 servers as they will already be up to 818 level?
thanks
alan
"Steve Kass" wrote:
> I suspect applying MS03-031 to the servers that are already at
> 8.00.837 will do nothing - it shouldn't overwrite files with
> earlier versions, and you can compare the file information in the KB
> article http://support.microsoft.com/kb/821277 with what's on your
> servers.
> Is there a reason you think MS03-31 contains something that is
> not already installed as part of the 837 hotfix on the hotfixed boxes?
> Usually these things are cumulative, and especially since 818 was a
> security issue, I'd be surprised if MSFT gave out something numbered
> 8.00.837 that didn't fix prior security issues.
> Steve Kass
> Drew University
> cranfield wrote:
> >Hello
> >
> >We're about to apply the MS03-031 security rollup patch to upgrade our 90
> >SQL Servers from SP3a (760) to (818).
> >
> >Problem is we have applied a hotfix already to a couple of boxes which
> >ugraded SQL to version (837).
> >
> >What will happen when we apply MS03-031 to these boxes with the hotfix? Will
> >it fail and if so whats the solution?
> >
> >thank you
> >
> >-- cranfield, DBA
> >
> >
>

8144 error: sp_MSaddinitialarticle has too many arguments

I have two servers that I am connecting with Merge replication (SQL2k).
SERVER1 is the publisher and pushes a subscription to SERVER2. After the
snapshot is created, the Merge Agent runs but gets the following error:
Procedure or function sp_MSaddinitialarticle has too many arguments
specified. (Source SERVER2 (Data source); Error number: 8144)
The process could not deliver the snapshot to the Subscriber. (Source:
Merge Replication Provider (Agent); Error number: -2147201001)
Any ideas?
William Schmidt
This error is usually caused by schema changes that are not propagated from
Publisher to Subscribers. Can you check that and verify that schemas are up
to date on both servers.
"Wm" wrote:

> I have two servers that I am connecting with Merge replication (SQL2k).
> SERVER1 is the publisher and pushes a subscription to SERVER2. After the
> snapshot is created, the Merge Agent runs but gets the following error:
> Procedure or function sp_MSaddinitialarticle has too many arguments
> specified. (Source SERVER2 (Data source); Error number: 8144)
> The process could not deliver the snapshot to the Subscriber. (Source:
> Merge Replication Provider (Agent); Error number: -2147201001)
> Any ideas?
> William Schmidt
|||Yes, schema is the same. Detached SERVER1 DB, copied the mdf/ldf to SERVER2,
then reattached both DBs. So, right now, both DBs are identical in schema
and data. Only difference is that I've been trying to set up replication
from SERVER1, whatever that may do to the DB. However, I am (apparently)
successful at removing replication between tries.
"Mark" wrote:
[vbcol=seagreen]
> This error is usually caused by schema changes that are not propagated from
> Publisher to Subscribers. Can you check that and verify that schemas are up
> to date on both servers.
> "Wm" wrote:
|||can you do a select @.@.version on both sides of your replication solution?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Wm" <Wm@.discussions.microsoft.com> wrote in message
news:E2B4FE2E-BB1D-448B-9E79-14691E4BFF80@.microsoft.com...
> I have two servers that I am connecting with Merge replication (SQL2k).
> SERVER1 is the publisher and pushes a subscription to SERVER2. After the
> snapshot is created, the Merge Agent runs but gets the following error:
> Procedure or function sp_MSaddinitialarticle has too many arguments
> specified. (Source SERVER2 (Data source); Error number: 8144)
> The process could not deliver the snapshot to the Subscriber. (Source:
> Merge Replication Provider (Agent); Error number: -2147201001)
> Any ideas?
> William Schmidt
|||Hmmm...
8.00.760
8.00.818
"Hilary Cotter" wrote:

> can you do a select @.@.version on both sides of your replication solution?
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Wm" <Wm@.discussions.microsoft.com> wrote in message
> news:E2B4FE2E-BB1D-448B-9E79-14691E4BFF80@.microsoft.com...
>
>
|||I personally dont think that @.@.Version is a big issue here. The error that
you are presenting is caused sometimes when in the article properties you say
you would use spIns_... and that procedure doesnt exist in the subscriber
database.
Technically one would expect to see an error like Stored procedure not found
or something similar, but I have seen instances where you will see too many
parameters error rather than procedure not found error.
Make sure that you have all procedures in Subscriber.
-Nitin
"Wm" wrote:
[vbcol=seagreen]
> Hmmm...
> 8.00.760
> 8.00.818
> "Hilary Cotter" wrote:
|||There could be a problem if your replicated database(s) use a binary collation. This is covered in http://support.microsoft.com/kb/814032
I'm not sure that this is what is going on, but it happened to me...
The solution for me was to install the MS03-031 SQL patch.
HTH
jg

Quote:

Originally posted by Wm
Hmmm...
8.00.760
8.00.818

|||Thanks Hilary; thanks Nitin! Here is the culprit:
When Microsoft created one of the post-SP3 hotfixes, they changed the stored
procedure sp_MSaddinitialarticle by adding a parameter called
@.published_in_tran_pub. So when SERVER1 (build 818) tries to set up
replication with SERVER2 (build 760), the above mentioned stored procedure is
called on SERVER2 with too many parameters. So it IS a version
incompatibility after all.
I can't find the hotfix files anywhere so when I get a chance, I'm going to
reinstall SQL Server 2k on SERVER1 and bring it up to build 760 level (SP3a).
"Nitin" wrote:
[vbcol=seagreen]
> I personally dont think that @.@.Version is a big issue here. The error that
> you are presenting is caused sometimes when in the article properties you say
> you would use spIns_... and that procedure doesnt exist in the subscriber
> database.
> Technically one would expect to see an error like Stored procedure not found
> or something similar, but I have seen instances where you will see too many
> parameters error rather than procedure not found error.
> Make sure that you have all procedures in Subscriber.
> -Nitin
>
> "Wm" wrote:

7.00.1078_enu.exe on msde

Hello does anyone know how to apply this patch on msde. I am getting
the rootkit.h in some of my servers and this patch requires to run
some querys. thanks.Hi

Has Sp4 been installed on those MSDE Instances?

What is the SELECT @.@.version for them?

http://www.microsoft.com/sql/downloads/sp4.asp

--
----------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@.epprecht.net

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

<jcharth@.hotmail.com> wrote in message
news:1115245790.849461.5680@.o13g2000cwo.googlegrou ps.com...
> Hello does anyone know how to apply this patch on msde. I am getting
> the rootkit.h in some of my servers and this patch requires to run
> some querys. thanks.

64-bit server deployment from 32-bit workstations

Our workstations (XP SP2) and development servers (2003 R2) are all 32-bit.Our Staging and Production SQL Servers are 64-bit (2003 R2 x64).We have some VB SQLCLR assemblies we've developed.

My question is: Do we have to do anything special when deploying a CLR Assembly to a 64-bit box when it has been compiled on a 32-bit box?Are there any advantages to setting the Target CPU from "AnyCPU" to "x64"?Documentation and testing seems to indicate that the assembly will run in 64-bit mode if compiled to "AnyCPU".

Will it run "better" in 64-bit mode with the "x64" Target CPU type?

Thanks!
There is nothing special you have to for assemblies to run on both 32-bit and 64-bit without any changes. You just need to be sure you have not made the assemblies architecture specific accidentally. By default, assemblies are MSIL unless the user specifies an architecture, runs ngen on them, or uses PInvoke.

To verify what architecture your assemblies are, do select * from sys.assemblies in your database, and look at the clr_name for the assembly. If you see processorarchitecture=msil or it is missing, then the assembly is architecture independent.

In your case, there is no advantage to specifing Target CPU as x64 because it will make deployment more complicated as you will have compile different assemblies for development and production. The "x64" Target CPU type is only useful if you were using PInvoke or some other CLR feature that made your binary architecture specific. The JIT will optimize the code just fine for each archiecture from the MSIL version.|||Thanks!

64-bit Restore via 32-bit GUI

Hello all,
I'm trying to use the 32-bit GUI, on a remote server, to restore a database
on one of our 64-bit servers. The GUI returns a prompt that the restore was
successful but the GUI indicates that the database is in a Loading mode. I
tried to issue a recovery command but it fails saying that some of the files
were partially restored.
I figured that there is a problem using the 32-bit client utility so I used
OSQL, via SQL Server Agent, on the 64-bit to ensure that I was using a
compatible 64-bit utility. By doing so, I was able to restore the database
successfully.
So my question is, is not being able to restore a 64-bit database via a
32-bit GUI, on a remote server, a known issue?
Thanks...Not that I'm aware of. EM is simply building the restore command and
sending it to the server. Try it again with EM but capture the command with
profiler. You can then determine if the command generated is good. Did you
change the recovery to Leave database nonoperational?
"BATMAN" <BATMAN@.discussions.microsoft.com> wrote in message
news:CA08652F-A880-48E8-A03B-1567EE5145A6@.microsoft.com...
> Hello all,
> I'm trying to use the 32-bit GUI, on a remote server, to restore a
> database
> on one of our 64-bit servers. The GUI returns a prompt that the restore
> was
> successful but the GUI indicates that the database is in a Loading mode.
> I
> tried to issue a recovery command but it fails saying that some of the
> files
> were partially restored.
> I figured that there is a problem using the 32-bit client utility so I
> used
> OSQL, via SQL Server Agent, on the 64-bit to ensure that I was using a
> compatible 64-bit utility. By doing so, I was able to restore the
> database
> successfully.
> So my question is, is not being able to restore a 64-bit database via a
> 32-bit GUI, on a remote server, a known issue?
> Thanks...
>

64-bit Restore via 32-bit GUI

Hello all,
I'm trying to use the 32-bit GUI, on a remote server, to restore a database
on one of our 64-bit servers. The GUI returns a prompt that the restore was
successful but the GUI indicates that the database is in a Loading mode. I
tried to issue a recovery command but it fails saying that some of the files
were partially restored.
I figured that there is a problem using the 32-bit client utility so I used
OSQL, via SQL Server Agent, on the 64-bit to ensure that I was using a
compatible 64-bit utility. By doing so, I was able to restore the database
successfully.
So my question is, is not being able to restore a 64-bit database via a
32-bit GUI, on a remote server, a known issue?
Thanks...
Not that I'm aware of. EM is simply building the restore command and
sending it to the server. Try it again with EM but capture the command with
profiler. You can then determine if the command generated is good. Did you
change the recovery to Leave database nonoperational?
"BATMAN" <BATMAN@.discussions.microsoft.com> wrote in message
news:CA08652F-A880-48E8-A03B-1567EE5145A6@.microsoft.com...
> Hello all,
> I'm trying to use the 32-bit GUI, on a remote server, to restore a
> database
> on one of our 64-bit servers. The GUI returns a prompt that the restore
> was
> successful but the GUI indicates that the database is in a Loading mode.
> I
> tried to issue a recovery command but it fails saying that some of the
> files
> were partially restored.
> I figured that there is a problem using the 32-bit client utility so I
> used
> OSQL, via SQL Server Agent, on the 64-bit to ensure that I was using a
> compatible 64-bit utility. By doing so, I was able to restore the
> database
> successfully.
> So my question is, is not being able to restore a 64-bit database via a
> 32-bit GUI, on a remote server, a known issue?
> Thanks...
>

64-bit Restore via 32-bit GUI

Hello all,
I'm trying to use the 32-bit GUI, on a remote server, to restore a database
on one of our 64-bit servers. The GUI returns a prompt that the restore was
successful but the GUI indicates that the database is in a Loading mode. I
tried to issue a recovery command but it fails saying that some of the files
were partially restored.
I figured that there is a problem using the 32-bit client utility so I used
OSQL, via SQL Server Agent, on the 64-bit to ensure that I was using a
compatible 64-bit utility. By doing so, I was able to restore the database
successfully.
So my question is, is not being able to restore a 64-bit database via a
32-bit GUI, on a remote server, a known issue?
Thanks...Not that I'm aware of. EM is simply building the restore command and
sending it to the server. Try it again with EM but capture the command with
profiler. You can then determine if the command generated is good. Did you
change the recovery to Leave database nonoperational?
"BATMAN" <BATMAN@.discussions.microsoft.com> wrote in message
news:CA08652F-A880-48E8-A03B-1567EE5145A6@.microsoft.com...
> Hello all,
> I'm trying to use the 32-bit GUI, on a remote server, to restore a
> database
> on one of our 64-bit servers. The GUI returns a prompt that the restore
> was
> successful but the GUI indicates that the database is in a Loading mode.
> I
> tried to issue a recovery command but it fails saying that some of the
> files
> were partially restored.
> I figured that there is a problem using the 32-bit client utility so I
> used
> OSQL, via SQL Server Agent, on the 64-bit to ensure that I was using a
> compatible 64-bit utility. By doing so, I was able to restore the
> database
> successfully.
> So my question is, is not being able to restore a 64-bit database via a
> 32-bit GUI, on a remote server, a known issue?
> Thanks...
>

64bit Proc Cache limit?

I understand that there is a 2Gb limit to SQL Server's procedure cache,
although I have found no official MS documentation that says so...
My question is whether the 64bit version suffers the same limit? Any input
and especially documentation would be much appreciated.
There are no such restrictions in 64bit. Virtually all of the available
memory for SQL Server is dynamic.
Andrew J. Kelly SQL MVP
"Don Peterson" <no1@.nunya.com> wrote in message
news:#Z6TidVKEHA.3580@.TK2MSFTNGP10.phx.gbl...
> I understand that there is a 2Gb limit to SQL Server's procedure cache,
> although I have found no official MS documentation that says so...
> My question is whether the 64bit version suffers the same limit? Any
input
> and especially documentation would be much appreciated.
>

64bit Mirrored SQL Server Std with 32bit Witness?

I have two 64bit SQL Server Std servers that will be principal and mirror. I also need to stand up a witness. I already understand that the witness can be any version of SQL Server, but can the witness server be 32bit given the principal and mirror are 64bit?

Yes the witness can be 32-bit, I use a 32-bit Workgroup Edition witness with 64-bit Enterprise Edition Principal and Mirror.

64 bit SQL

Why bother? Planning on building new servers in the next 6 months. Any point
in dumping 32 bit?
Bob Castleman
DBA PoseurBob,
A little more background would help; What is your memory utilization like
in 32-bit? Are in in an Active/Active cluster and unable to take advantage
of AWE? What are some characteristics of your workload? With the
information I have right now I couldn't even help you choose your next car,
let-alone where your I.T. budget dollars need to go. =)
"Bob Castleman" wrote:

> Why bother? Planning on building new servers in the next 6 months. Any poi
nt
> in dumping 32 bit?
> Bob Castleman
> DBA Poseur
>
>|||Not enough info. Guilty as charged.
Current environment is a two node active-passive cluster. Currently 4
processors, 16 gig RAM. going to add 4 procs and 16 Gigs Ram this wend.
Fiber chanel to an array.
We are looking into a building a cluster with more nodes
(Active-Active-Passive, maybe).
Biggest problems are that the application is a port from an Access database
and we serve the appliction to about 200 customers, growing fast (20% per
quarter). It has not, and very likely will never be, optimized in any
meanigful way for SQL Server. Another fun thing is that each instance of
the application creates multiple database connections and leaves them open
until the user exits. This amounts to thousands of open connections at peak
times.
Bob
"Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
> Bob,
> A little more background would help; What is your memory utilization like
> in 32-bit? Are in in an Active/Active cluster and unable to take
> advantage
> of AWE? What are some characteristics of your workload? With the
> information I have right now I couldn't even help you choose your next
> car,
> let-alone where your I.T. budget dollars need to go. =)
>
> "Bob Castleman" wrote:
>|||"Bob Castleman" <nomail@.here> wrote in message
news:Op22C6GbFHA.2124@.TK2MSFTNGP14.phx.gbl...
> Why bother? Planning on building new servers in the next 6 months. Any
point
> in dumping 32 bit?
> Bob Castleman
> DBA Poseur
>
Any point in staying 32-bit?
Buy dual-core capable Opteron machines. The licensing fee structure makes it
irresponsible to buy anything else.|||I'd get a 2005 Ford Mustang 4.6L, Dark Platinum with Charcoal leather...
"Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
> Bob,
> A little more background would help; What is your memory utilization like
> in 32-bit? Are in in an Active/Active cluster and unable to take
advantage
> of AWE? What are some characteristics of your workload? With the
> information I have right now I couldn't even help you choose your next
car,
> let-alone where your I.T. budget dollars need to go. =)
>
> "Bob Castleman" wrote:
>
point|||I had an '02 GT Couple with a Vortech SQ trim blower and 4.10 rear gears...
and then Indiana winter taught me a lesson about traction and physics. =/
"Ty Salistean" wrote:

> I'd get a 2005 Ford Mustang 4.6L, Dark Platinum with Charcoal leather...
> "Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
> news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
> advantage
> car,
> point
>
>|||Superficially (based on what you've provided), I wouldn't bother going to 64
bit until the situation is more under control. All real-world reports I've
heard of are having various issues with 64-bit handling some of the basic
functionality 32-bit delivers without issue (memory leak in the dynamic proc
cache, issues with linked servers, replication, etc). If your app isn't
tuned yet, you're going to get more bang for your buck throwing intelligent
design at it instead of 64-bit / hardware.
"Bob Castleman" wrote:

> Not enough info. Guilty as charged.
> Current environment is a two node active-passive cluster. Currently 4
> processors, 16 gig RAM. going to add 4 procs and 16 Gigs Ram this wend.
> Fiber chanel to an array.
> We are looking into a building a cluster with more nodes
> (Active-Active-Passive, maybe).
> Biggest problems are that the application is a port from an Access databas
e
> and we serve the appliction to about 200 customers, growing fast (20% per
> quarter). It has not, and very likely will never be, optimized in any
> meanigful way for SQL Server. Another fun thing is that each instance of
> the application creates multiple database connections and leaves them open
> until the user exits. This amounts to thousands of open connections at pea
k
> times.
> Bob
>
> "Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
> news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
>
>|||Hi
I agree with Cris.
Whilst you are at it, why not buy a Unisys ES 7000?
If it is easier to throw pots of money at a bad application to buy hardware,
you might as well buy the top of the range as you will probably still need
it soon.
Get the application fixed, and save yourself a lot of trouble. Eventually
you will not be able to scale up any more and your business grinds to a
halt.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
news:90A70D9A-95AA-4CA8-96D2-678DD574F3C2@.microsoft.com...
> Superficially (based on what you've provided), I wouldn't bother going to
> 64
> bit until the situation is more under control. All real-world reports
> I've
> heard of are having various issues with 64-bit handling some of the basic
> functionality 32-bit delivers without issue (memory leak in the dynamic
> proc
> cache, issues with linked servers, replication, etc). If your app isn't
> tuned yet, you're going to get more bang for your buck throwing
> intelligent
> design at it instead of 64-bit / hardware.
> "Bob Castleman" wrote:
>

64 bit Implementation, and Linked Server to Access DB

Can anyone suggest a method to connect to an Access DB from 64 bit
implementation of Yukon ?
Regardless of whether I use Linked Servers or Opendatasource I get the
following error:
"The OLE DB provider "MICROSOFT.JET.OLEDB.4.0" has not been
registered."
If there isn't a 64 bit driver available ..what alternative mechanisms
are available to load data from Access ?
TIAThere is unfortunately no 64-bit version of Jet. You'll need to use a
32-bit version to move your data.
Conor
"MJKulangara" <RutgersDBA@.gmail.com> wrote in message
news:1151430037.910336.142450@.x69g2000cwx.googlegroups.com...
> Can anyone suggest a method to connect to an Access DB from 64 bit
> implementation of Yukon ?
> Regardless of whether I use Linked Servers or Opendatasource I get the
> following error:
> "The OLE DB provider "MICROSOFT.JET.OLEDB.4.0" has not been
> registered."
> If there isn't a 64 bit driver available ..what alternative mechanisms
> are available to load data from Access ?
> TIA
>

64 bit Implementation, and Linked Server to Access DB

Can anyone suggest a method to connect to an Access DB from 64 bit
implementation of Yukon ?
Regardless of whether I use Linked Servers or Opendatasource I get the
following error:
"The OLE DB provider "MICROSOFT.JET.OLEDB.4.0" has not been
registered."
If there isn't a 64 bit driver available ..what alternative mechanisms
are available to load data from Access ?
TIAThere is unfortunately no 64-bit version of Jet. You'll need to use a
32-bit version to move your data.
Conor
"MJKulangara" <RutgersDBA@.gmail.com> wrote in message
news:1151430037.910336.142450@.x69g2000cwx.googlegroups.com...
> Can anyone suggest a method to connect to an Access DB from 64 bit
> implementation of Yukon ?
> Regardless of whether I use Linked Servers or Opendatasource I get the
> following error:
> "The OLE DB provider "MICROSOFT.JET.OLEDB.4.0" has not been
> registered."
> If there isn't a 64 bit driver available ..what alternative mechanisms
> are available to load data from Access ?
> TIA
>|||There is unfortunately no 64-bit version of Jet. You'll need to use a
32-bit version to move your data.
Conor
"MJKulangara" <RutgersDBA@.gmail.com> wrote in message
news:1151430037.910336.142450@.x69g2000cwx.googlegroups.com...
> Can anyone suggest a method to connect to an Access DB from 64 bit
> implementation of Yukon ?
> Regardless of whether I use Linked Servers or Opendatasource I get the
> following error:
> "The OLE DB provider "MICROSOFT.JET.OLEDB.4.0" has not been
> registered."
> If there isn't a 64 bit driver available ..what alternative mechanisms
> are available to load data from Access ?
> TIA
>

64 bit Edition and 32bit Participate in VIRTUALSQL Cluster

Hi All

I have a requiment to update a SQL Cluster that I have, however we only have the budget to upgrade one of the servers participating in the Cluster.

Older servers are ML370 G4 Dual 3Ghz 10GB RAM - Windows 2003 Enterprise (existing)

the server I want to upgrade to is a

DL380 G5 Quad 3Ghz (Duo) - 20GB RAM - Windows 2003 Enterprise x64 edition (new)

I would also be upgrading to SQL 2005 Enterprise in the same upgrade (x64 edition on the new server)

What I want to know is if a x64bit Edition and a standard x86 edition both participate in the same VIRTUALSQL instance in a clustered environment?

Would appreciate assistance from any Microsoft people reading this post?

No,

All instances of SQL Server participating in a Cluster must be the same -either 32 bit or 64 bit.

However, you may want to consider running 32 bit SQL Server on the 64 bit Windows Server.

Or, you may forgo the Cluster, and using the 64 bit SQL Server as primary, create a Mirror server with the 32 bit server as a fail-over partner.

|||If you've got the cash for a SQL 2005 Enterprise license and a single DL380 don't skimp. Purchase another DL380, they aren't that expensive.

64 Bit and 32 Bit Reporting Servers in same web farm

Can I mix 64 Bit and 32 Bit Reporting Servers in same web farm? I currently have a distributed environment with 2 32 Bit Web Servers and a 32 Bit Reporting Services Database server. I would like to add 64 Bit web servers to this configuration. Are there any issues with this?

This wasn't really a tested scenario, but I think in theory it should work. I mean I don't see anything in the RS product code that prevents you from doing so. It's always interesting when a theory is put to test though :).

If you decide to go down this route, let us know any problems you find.

4GB Ram for SQL

Hi all,
I have a new server with 4GB Ram and I want SQL server
use most of ram.
I have licences for Windows 2003 standard and enterprise
servers and SQL 2000 standard and enterprise servers.
Could anyone tell me which versions of Win2003 and
SQL2000 is better for SQL perforemance.
Thanks
MIkeHow many processors? Is anything else running on the box, or is it
dedicated to SQL Server? How busy will the server be? You can also list
the brand/model of server which might help.
"Mike" <anonymous@.discussions.microsoft.com> wrote in message
news:175b01c4b569$e7919d90$a301280a@.phx.gbl...
> Hi all,
> I have a new server with 4GB Ram and I want SQL server
> use most of ram.
> I have licences for Windows 2003 standard and enterprise
> servers and SQL 2000 standard and enterprise servers.
> Could anyone tell me which versions of Win2003 and
> SQL2000 is better for SQL perforemance.
> Thanks
> MIke|||Hi Derrick,
Thanks your reply
It is IBM xSeries 345 with Dual 3.06GHz CPUs and 4GB ram,
which is Payroll server and will have SQL server and
application software on.
Thanks
Mike
>--Original Message--
>How many processors? Is anything else running on the
box, or is it
>dedicated to SQL Server? How busy will the server be?
You can also list
>the brand/model of server which might help.
>
>"Mike" <anonymous@.discussions.microsoft.com> wrote in
message
>news:175b01c4b569$e7919d90$a301280a@.phx.gbl...
>> Hi all,
>> I have a new server with 4GB Ram and I want SQL server
>> use most of ram.
>> I have licences for Windows 2003 standard and
enterprise
>> servers and SQL 2000 standard and enterprise servers.
>> Could anyone tell me which versions of Win2003 and
>> SQL2000 is better for SQL perforemance.
>> Thanks
>> MIke
>
>.
>|||You have to use SQL Server Enterprise to access more than 2 GB of memory.
Not sure if you can run that on Win2003 Standard or if you need Enterprise.
However since you have a separate payroll application running on the same
SQL Server box you wouldn't want to have SQL eat up all the memory.
"Mike" <anonymous@.discussions.microsoft.com> wrote in message
news:175b01c4b569$e7919d90$a301280a@.phx.gbl...
> Hi all,
> I have a new server with 4GB Ram and I want SQL server
> use most of ram.
> I have licences for Windows 2003 standard and enterprise
> servers and SQL 2000 standard and enterprise servers.
> Could anyone tell me which versions of Win2003 and
> SQL2000 is better for SQL perforemance.
> Thanks
> MIke|||I'd run Windows 2003 Enterprise and SQL Server Standard if I were you. You
will only want SQL Server using 2GB of RAM anyway if the app is on there
also. I would actually recommend setting the max memory for SQL to 1GB and
monitoring performance. You can then set up higher if need be.
The reason for this is licensing cost. You'll save yourself about $26,000
going this route. If you need Enterprise Edition, you will also need more
RAM. 4GB won't cut it because you don't want to starve the app out. You
also don't want to use the /3GB switch if it's a shared app/sql server.
That IBM has 8 memory slots if my recollection is right, so upgrading
shouldn't be a problem later. It's easy to upgrade to EM. You don't want
to have to reinstall the OS later though if 2003 standard doesn't work for
you.
"Peter Yao" <peteryao@.NoSPAMhotmail.com> wrote in message
news:OLXQPMYtEHA.3572@.tk2msftngp13.phx.gbl...
> You have to use SQL Server Enterprise to access more than 2 GB of memory.
> Not sure if you can run that on Win2003 Standard or if you need
Enterprise.
> However since you have a separate payroll application running on the same
> SQL Server box you wouldn't want to have SQL eat up all the memory.
> "Mike" <anonymous@.discussions.microsoft.com> wrote in message
> news:175b01c4b569$e7919d90$a301280a@.phx.gbl...
> > Hi all,
> > I have a new server with 4GB Ram and I want SQL server
> > use most of ram.
> > I have licences for Windows 2003 standard and enterprise
> > servers and SQL 2000 standard and enterprise servers.
> > Could anyone tell me which versions of Win2003 and
> > SQL2000 is better for SQL perforemance.
> > Thanks
> > MIke
>|||Thanks a lot
MIke
>--Original Message--
>I'd run Windows 2003 Enterprise and SQL Server Standard
if I were you. You
>will only want SQL Server using 2GB of RAM anyway if the
app is on there
>also. I would actually recommend setting the max memory
for SQL to 1GB and
>monitoring performance. You can then set up higher if
need be.
>The reason for this is licensing cost. You'll save
yourself about $26,000
>going this route. If you need Enterprise Edition, you
will also need more
>RAM. 4GB won't cut it because you don't want to starve
the app out. You
>also don't want to use the /3GB switch if it's a shared
app/sql server.
>That IBM has 8 memory slots if my recollection is right,
so upgrading
>shouldn't be a problem later. It's easy to upgrade to
EM. You don't want
>to have to reinstall the OS later though if 2003
standard doesn't work for
>you.
>
>"Peter Yao" <peteryao@.NoSPAMhotmail.com> wrote in message
>news:OLXQPMYtEHA.3572@.tk2msftngp13.phx.gbl...
>> You have to use SQL Server Enterprise to access more
than 2 GB of memory.
>> Not sure if you can run that on Win2003 Standard or if
you need
>Enterprise.
>> However since you have a separate payroll application
running on the same
>> SQL Server box you wouldn't want to have SQL eat up
all the memory.
>> "Mike" <anonymous@.discussions.microsoft.com> wrote in
message
>> news:175b01c4b569$e7919d90$a301280a@.phx.gbl...
>> > Hi all,
>> > I have a new server with 4GB Ram and I want SQL
server
>> > use most of ram.
>> > I have licences for Windows 2003 standard and
enterprise
>> > servers and SQL 2000 standard and enterprise servers.
>> > Could anyone tell me which versions of Win2003 and
>> > SQL2000 is better for SQL perforemance.
>> > Thanks
>> > MIke
>>
>
>.
>

403 Forbidden Error

Hi,
We have configured the SRS report in IIS 6.0. We are able to see the reports
in the servers but if we click on report we are getting 403 Forbidden error.
Can you please let know the resolution on the same?
ManjunathanOn Dec 7, 8:57 am, Manjunathan <Manjunat...@.discussions.microsoft.com>
wrote:
> Hi,
> We have configured the SRS report in IIS 6.0. We are able to see the reports
> in the servers but if we click on report we are getting 403 Forbidden error.
> Can you please let know the resolution on the same?
> Manjunathan
This link might be helpful.
http://msdn2.microsoft.com/en-us/library/ms159778.aspx
Regards,
Enrique Martinez
Sr. Software Consultant