Showing posts with label servers. Show all posts
Showing posts with label servers. Show all posts

Thursday, March 29, 2012

Direct vs. Indirect Package Configurations

If your XML configuration files will be in the same location on your Development, UAT and PROD servers, is there any merit to making your configurations indirect?

I am modifying the connection string with the XML. My strategy is to set up an XML configuration for each database that we have. The Dev XML config will point to Development connection, UAT to UAT etc..

My thought is that by using the direct configuration it will eliminate the need for environment variables and also allow me to add configs without having to reboot the servers, which you would need to do in order to get server to recongize the EV.

Thanks

There isn't in real advantage to using indirect XML configurations if you're 100% sure that the location of your configuration file is never going to change and be identical in development, staging, and production environments. However, indirect configuration are a huge advantage if the location of your configuration files should change. Our project has over 50 SSIS packages (and growing) and I would hate to be the poor sap that would have to go change and test each and every package should the configuration file location ever was changed.|||

By the way, I wrote a batch configuration changer that you can use to modify the configuration settings in a group of packages. It's available as part of the downloadable samples for my book. A few have used it and saved some time with it.

It's called ConfigBatch.exe.

You can select a set of packages and bulk add, delete, modify configurations within those packages.

K

|||

Dear Kirk,

I got your book, and downloaded the samples. For the Config utility you included an msi, but the batch utility was a c# project. I don't have c# in my visual studio, could you perhaps mail an msi or .exe?

btw, the book is very readable so far (I'm at chapter 4).

thanks,

John.

Direct vs. Indirect Package Configurations

If your XML configuration files will be in the same location on your Development, UAT and PROD servers, is there any merit to making your configurations indirect?

I am modifying the connection string with the XML. My strategy is to set up an XML configuration for each database that we have. The Dev XML config will point to Development connection, UAT to UAT etc..

My thought is that by using the direct configuration it will eliminate the need for environment variables and also allow me to add configs without having to reboot the servers, which you would need to do in order to get server to recongize the EV.

Thanks

There isn't in real advantage to using indirect XML configurations if you're 100% sure that the location of your configuration file is never going to change and be identical in development, staging, and production environments. However, indirect configuration are a huge advantage if the location of your configuration files should change. Our project has over 50 SSIS packages (and growing) and I would hate to be the poor sap that would have to go change and test each and every package should the configuration file location ever was changed.|||

By the way, I wrote a batch configuration changer that you can use to modify the configuration settings in a group of packages. It's available as part of the downloadable samples for my book. A few have used it and saved some time with it.

It's called ConfigBatch.exe.

You can select a set of packages and bulk add, delete, modify configurations within those packages.

K

|||

Dear Kirk,

I got your book, and downloaded the samples. For the Config utility you included an msi, but the batch utility was a c# project. I don't have c# in my visual studio, could you perhaps mail an msi or .exe?

btw, the book is very readable so far (I'm at chapter 4).

thanks,

John.

Direct vs. Indirect Package Configurations

If your XML configuration files will be in the same location on your Development, UAT and PROD servers, is there any merit to making your configurations indirect?

I am modifying the connection string with the XML. My strategy is to set up an XML configuration for each database that we have. The Dev XML config will point to Development connection, UAT to UAT etc..

My thought is that by using the direct configuration it will eliminate the need for environment variables and also allow me to add configs without having to reboot the servers, which you would need to do in order to get server to recongize the EV.

Thanks

There isn't in real advantage to using indirect XML configurations if you're 100% sure that the location of your configuration file is never going to change and be identical in development, staging, and production environments. However, indirect configuration are a huge advantage if the location of your configuration files should change. Our project has over 50 SSIS packages (and growing) and I would hate to be the poor sap that would have to go change and test each and every package should the configuration file location ever was changed.|||

By the way, I wrote a batch configuration changer that you can use to modify the configuration settings in a group of packages. It's available as part of the downloadable samples for my book. A few have used it and saved some time with it.

It's called ConfigBatch.exe.

You can select a set of packages and bulk add, delete, modify configurations within those packages.

K

|||

Dear Kirk,

I got your book, and downloaded the samples. For the Config utility you included an msi, but the batch utility was a c# project. I don't have c# in my visual studio, could you perhaps mail an msi or .exe?

btw, the book is very readable so far (I'm at chapter 4).

thanks,

John.

Monday, March 19, 2012

Differing collations for database and server - How big a problem is it?

I am using 3 servers. They are SQL all Server Express. I just noticed
that they are all outof sync wrt. Versions and Collation. has there
been a SQL Server Express service pack released? I seem to remember one.
Live
====
Version:9.00.3042.00
Collation:Latin1_General_CI_AS
Development
===========
Version:9.00.3054.00
Collation:SQL_Latin1_General_CP1_CI_AS
Stage
=====
Version:9.00.2047.00
Collation:Latin1_General_CI_AS
1. What is the best solution to this collation problem? To alter the
Development server? - I guess so, but there's another related problem.
My main application database is using 'SQL_Latin1_General_CP1_CI_AS'!
[I have script to convert the collations so I don't need to
re-install]. Yep that's a database with SQL_Latin1_General_CP1_CI_AS
collation sitting on a server using Latin1_General_CI_AS collation.
Does it matter which of these 2 collations I use:Latin1_General_CI_AS
or SQL_Latin1_General_CP1_CI_AS?
2. Two of these servers (Live, Development) have had the SQL service
pack installed but why do those two have different version numbers? Is
it the case that some of the ordinary microsoft updates also update SQL
Server Express? I noticed that the provider who runs the Live site does
not add all the microsoft service packs and even when adding service
packs waits a while until they are 'proven in the field'. The Stage
server has probably not has the service pack - so I guess that explains
the version number.
Hi,
The collation is more important in database. Since sql 2000 I can have a
different server collation from database collation.
If you want link diferent servers, You must be in mind the collations of
databases.
The important is (again) that the databases in differents enviroments, have
the same collation.
Regards,
"mark4asp" wrote:

> I am using 3 servers. They are SQL all Server Express. I just noticed
> that they are all outof sync wrt. Versions and Collation. has there
> been a SQL Server Express service pack released? I seem to remember one.
> Live
> ====
> Version:9.00.3042.00
> Collation:Latin1_General_CI_AS
> Development
> ===========
> Version:9.00.3054.00
> Collation:SQL_Latin1_General_CP1_CI_AS
> Stage
> =====
> Version:9.00.2047.00
> Collation:Latin1_General_CI_AS
> 1. What is the best solution to this collation problem? To alter the
> Development server? - I guess so, but there's another related problem.
> My main application database is using 'SQL_Latin1_General_CP1_CI_AS'!
> [I have script to convert the collations so I don't need to
> re-install]. Yep that's a database with SQL_Latin1_General_CP1_CI_AS
> collation sitting on a server using Latin1_General_CI_AS collation.
> Does it matter which of these 2 collations I use:Latin1_General_CI_AS
> or SQL_Latin1_General_CP1_CI_AS?
> 2. Two of these servers (Live, Development) have had the SQL service
> pack installed but why do those two have different version numbers? Is
> it the case that some of the ordinary microsoft updates also update SQL
> Server Express? I noticed that the provider who runs the Live site does
> not add all the microsoft service packs and even when adding service
> packs waits a while until they are 'proven in the field'. The Stage
> server has probably not has the service pack - so I guess that explains
> the version number.
>
|||Another thing:
the version must be the same, is very important especially when you try to
do maintenance tasks. The results can be differents between servers.
Put Your servers in the same version
9.00.3054
Regards,
"Carlos A." wrote:
[vbcol=seagreen]
> Hi,
> The collation is more important in database. Since sql 2000 I can have a
> different server collation from database collation.
> If you want link diferent servers, You must be in mind the collations of
> databases.
> The important is (again) that the databases in differents enviroments, have
> the same collation.
>
> Regards,
>
> "mark4asp" wrote:

Differing collations for database and server - How big a problem is it?

I am using 3 servers. They are SQL all Server Express. I just noticed
that they are all outof sync wrt. Versions and Collation. has there
been a SQL Server Express service pack released? I seem to remember one.
Live
==== Version: 9.00.3042.00
Collation: Latin1_General_CI_AS
Development
=========== Version: 9.00.3054.00
Collation: SQL_Latin1_General_CP1_CI_AS
Stage
===== Version: 9.00.2047.00
Collation: Latin1_General_CI_AS
1. What is the best solution to this collation problem? To alter the
Development server? - I guess so, but there's another related problem.
My main application database is using 'SQL_Latin1_General_CP1_CI_AS'!
[I have script to convert the collations so I don't need to
re-install]. Yep that's a database with SQL_Latin1_General_CP1_CI_AS
collation sitting on a server using Latin1_General_CI_AS collation.
Does it matter which of these 2 collations I use: Latin1_General_CI_AS
or SQL_Latin1_General_CP1_CI_AS?
2. Two of these servers (Live, Development) have had the SQL service
pack installed but why do those two have different version numbers? Is
it the case that some of the ordinary microsoft updates also update SQL
Server Express? I noticed that the provider who runs the Live site does
not add all the microsoft service packs and even when adding service
packs waits a while until they are 'proven in the field'. The Stage
server has probably not has the service pack - so I guess that explains
the version number.Hi,
The collation is more important in database. Since sql 2000 I can have a
different server collation from database collation.
If you want link diferent servers, You must be in mind the collations of
databases.
The important is (again) that the databases in differents enviroments, have
the same collation.
Regards,
"mark4asp" wrote:
> I am using 3 servers. They are SQL all Server Express. I just noticed
> that they are all outof sync wrt. Versions and Collation. has there
> been a SQL Server Express service pack released? I seem to remember one.
> Live
> ====> Version: 9.00.3042.00
> Collation: Latin1_General_CI_AS
> Development
> ===========> Version: 9.00.3054.00
> Collation: SQL_Latin1_General_CP1_CI_AS
> Stage
> =====> Version: 9.00.2047.00
> Collation: Latin1_General_CI_AS
> 1. What is the best solution to this collation problem? To alter the
> Development server? - I guess so, but there's another related problem.
> My main application database is using 'SQL_Latin1_General_CP1_CI_AS'!
> [I have script to convert the collations so I don't need to
> re-install]. Yep that's a database with SQL_Latin1_General_CP1_CI_AS
> collation sitting on a server using Latin1_General_CI_AS collation.
> Does it matter which of these 2 collations I use: Latin1_General_CI_AS
> or SQL_Latin1_General_CP1_CI_AS?
> 2. Two of these servers (Live, Development) have had the SQL service
> pack installed but why do those two have different version numbers? Is
> it the case that some of the ordinary microsoft updates also update SQL
> Server Express? I noticed that the provider who runs the Live site does
> not add all the microsoft service packs and even when adding service
> packs waits a while until they are 'proven in the field'. The Stage
> server has probably not has the service pack - so I guess that explains
> the version number.
>|||Another thing:
the version must be the same, is very important especially when you try to
do maintenance tasks. The results can be differents between servers.
Put Your servers in the same version
9.00.3054
Regards,
"Carlos A." wrote:
> Hi,
> The collation is more important in database. Since sql 2000 I can have a
> different server collation from database collation.
> If you want link diferent servers, You must be in mind the collations of
> databases.
> The important is (again) that the databases in differents enviroments, have
> the same collation.
>
> Regards,
>
> "mark4asp" wrote:
> > I am using 3 servers. They are SQL all Server Express. I just noticed
> > that they are all outof sync wrt. Versions and Collation. has there
> > been a SQL Server Express service pack released? I seem to remember one.
> >
> > Live
> > ====> > Version: 9.00.3042.00
> > Collation: Latin1_General_CI_AS
> >
> > Development
> > ===========> > Version: 9.00.3054.00
> > Collation: SQL_Latin1_General_CP1_CI_AS
> >
> > Stage
> > =====> > Version: 9.00.2047.00
> > Collation: Latin1_General_CI_AS
> >
> > 1. What is the best solution to this collation problem? To alter the
> > Development server? - I guess so, but there's another related problem.
> > My main application database is using 'SQL_Latin1_General_CP1_CI_AS'!
> > [I have script to convert the collations so I don't need to
> > re-install]. Yep that's a database with SQL_Latin1_General_CP1_CI_AS
> > collation sitting on a server using Latin1_General_CI_AS collation.
> >
> > Does it matter which of these 2 collations I use: Latin1_General_CI_AS
> > or SQL_Latin1_General_CP1_CI_AS?
> >
> > 2. Two of these servers (Live, Development) have had the SQL service
> > pack installed but why do those two have different version numbers? Is
> > it the case that some of the ordinary microsoft updates also update SQL
> > Server Express? I noticed that the provider who runs the Live site does
> > not add all the microsoft service packs and even when adding service
> > packs waits a while until they are 'proven in the field'. The Stage
> > server has probably not has the service pack - so I guess that explains
> > the version number.
> >

Friday, March 9, 2012

Different UPDATE behaviors across servers/databases

Hi!
I have a stored procedure that takes 22 minutes to run in one
environment, that only takes 1 sec or so to run in another
environment. Here is the exact situation:
Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
exactly the same, and the tables and index structures are exactly the
same. Implicit transactions are turned off on both databases.
Stored procedure:
BEGIN TRANSACTION
--step 1
TRUNCATE myTable
--step 2
INSERT INTO myTable VALUES ('myValues')
--step 3
UPDATE a
SET rating=AVG(someValues)
FROM myTable a
JOIN otherTable b
ON a.column1=b.column1
GROUP BY someColumns
COMMIT TRANSACTION
The update statement on the problem server is the only step that takes
forever. While it is running, I don't see anything that could be
blocking the statement. I used the following queries to determine if
there was another process blocking it:
select spid AS Blocked, blocked AS Blocking, waittime, cmd, substring
(nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where blocked <> 0
order by waittime desc
select dbid, name from sysdatabases where dbid in (select dbid from
master.dbo.sysprocesses where blocked <> 0)
select spid AS BlockingFromAbove, blocked AS TrueBlockingQuery,
waittime, cmd, substring (nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where spid in (select blocked from
master.dbo.sysprocesses where blocked <> 0)
order by waittime desc
When I change the UPDATE statement to a SELECT, it still takes longer
than it does on the test server (1 min 35 sec vs. several
milliseconds).
What could be causing the UPDATE to take forever on one server/
database, and run without a problem on another?
I am at a loss! Any help would be greatly appreciated.
Same execution plans on both server?
Also, when you say "data is exactly the same", does that mean whole database is identical, to the
point that one is a backup or attach of the other? If not, things like statistics can cause
different execution plans.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Baby Dragon" <nienna.gaia@.gmail.com> wrote in message
news:1177442708.864293.299400@.o40g2000prh.googlegr oups.com...
> Hi!
> I have a stored procedure that takes 22 minutes to run in one
> environment, that only takes 1 sec or so to run in another
> environment. Here is the exact situation:
> Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
> exactly the same, and the tables and index structures are exactly the
> same. Implicit transactions are turned off on both databases.
> Stored procedure:
> BEGIN TRANSACTION
> --step 1
> TRUNCATE myTable
> --step 2
> INSERT INTO myTable VALUES ('myValues')
> --step 3
> UPDATE a
> SET rating=AVG(someValues)
> FROM myTable a
> JOIN otherTable b
> ON a.column1=b.column1
> GROUP BY someColumns
> COMMIT TRANSACTION
> The update statement on the problem server is the only step that takes
> forever. While it is running, I don't see anything that could be
> blocking the statement. I used the following queries to determine if
> there was another process blocking it:
> select spid AS Blocked, blocked AS Blocking, waittime, cmd, substring
> (nt_username, 1, 15), dbid, physical_io,
> substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
> memusage
> from master.dbo.sysprocesses where blocked <> 0
> order by waittime desc
> select dbid, name from sysdatabases where dbid in (select dbid from
> master.dbo.sysprocesses where blocked <> 0)
> select spid AS BlockingFromAbove, blocked AS TrueBlockingQuery,
> waittime, cmd, substring (nt_username, 1, 15), dbid, physical_io,
> substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
> memusage
> from master.dbo.sysprocesses where spid in (select blocked from
> master.dbo.sysprocesses where blocked <> 0)
> order by waittime desc
> When I change the UPDATE statement to a SELECT, it still takes longer
> than it does on the test server (1 min 35 sec vs. several
> milliseconds).
> What could be causing the UPDATE to take forever on one server/
> database, and run without a problem on another?
> I am at a loss! Any help would be greatly appreciated.
>
|||I will take a look at the execution plans and any statistics that are
captured.
Thanks!

Different UPDATE behaviors across servers/databases

Hi!
I have a stored procedure that takes 22 minutes to run in one
environment, that only takes 1 sec or so to run in another
environment. Here is the exact situation:
Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
exactly the same, and the tables and index structures are exactly the
same. Implicit transactions are turned off on both databases.
Stored procedure:
BEGIN TRANSACTION
--step 1
TRUNCATE myTable
--step 2
INSERT INTO myTable VALUES ('myValues')
--step 3
UPDATE a
SET rating=AVG(someValues)
FROM myTable a
JOIN otherTable b
ON a.column1=b.column1
GROUP BY someColumns
COMMIT TRANSACTION
The update statement on the problem server is the only step that takes
forever. While it is running, I don't see anything that could be
blocking the statement. I used the following queries to determine if
there was another process blocking it:
select spid AS Blocked, blocked AS Blocking, waittime, cmd, substring
(nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where blocked <> 0
order by waittime desc
select dbid, name from sysdatabases where dbid in (select dbid from
master.dbo.sysprocesses where blocked <> 0)
select spid AS BlockingFromAbove, blocked AS TrueBlockingQuery,
waittime, cmd, substring (nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where spid in (select blocked from
master.dbo.sysprocesses where blocked <> 0)
order by waittime desc
When I change the UPDATE statement to a SELECT, it still takes longer
than it does on the test server (1 min 35 sec vs. several
milliseconds).
What could be causing the UPDATE to take forever on one server/
database, and run without a problem on another?
I am at a loss! Any help would be greatly appreciated.Same execution plans on both server?
Also, when you say "data is exactly the same", does that mean whole database
is identical, to the
point that one is a backup or attach of the other? If not, things like stati
stics can cause
different execution plans.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Baby Dragon" <nienna.gaia@.gmail.com> wrote in message
news:1177442708.864293.299400@.o40g2000prh.googlegroups.com...
> Hi!
> I have a stored procedure that takes 22 minutes to run in one
> environment, that only takes 1 sec or so to run in another
> environment. Here is the exact situation:
> Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
> exactly the same, and the tables and index structures are exactly the
> same. Implicit transactions are turned off on both databases.
> Stored procedure:
> BEGIN TRANSACTION
> --step 1
> TRUNCATE myTable
> --step 2
> INSERT INTO myTable VALUES ('myValues')
> --step 3
> UPDATE a
> SET rating=AVG(someValues)
> FROM myTable a
> JOIN otherTable b
> ON a.column1=b.column1
> GROUP BY someColumns
> COMMIT TRANSACTION
> The update statement on the problem server is the only step that takes
> forever. While it is running, I don't see anything that could be
> blocking the statement. I used the following queries to determine if
> there was another process blocking it:
> select spid AS Blocked, blocked AS Blocking, waittime, cmd, substring
> (nt_username, 1, 15), dbid, physical_io,
> substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
> memusage
> from master.dbo.sysprocesses where blocked <> 0
> order by waittime desc
> select dbid, name from sysdatabases where dbid in (select dbid from
> master.dbo.sysprocesses where blocked <> 0)
> select spid AS BlockingFromAbove, blocked AS TrueBlockingQuery,
> waittime, cmd, substring (nt_username, 1, 15), dbid, physical_io,
> substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
> memusage
> from master.dbo.sysprocesses where spid in (select blocked from
> master.dbo.sysprocesses where blocked <> 0)
> order by waittime desc
> When I change the UPDATE statement to a SELECT, it still takes longer
> than it does on the test server (1 min 35 sec vs. several
> milliseconds).
> What could be causing the UPDATE to take forever on one server/
> database, and run without a problem on another?
> I am at a loss! Any help would be greatly appreciated.
>|||I will take a look at the execution plans and any statistics that are
captured.
Thanks!

Different UPDATE behaviors across servers/databases

Hi!
I have a stored procedure that takes 22 minutes to run in one
environment, that only takes 1 sec or so to run in another
environment. Here is the exact situation:
Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
exactly the same, and the tables and index structures are exactly the
same. Implicit transactions are turned off on both databases.
Stored procedure:
BEGIN TRANSACTION
--step 1
TRUNCATE myTable
--step 2
INSERT INTO myTable VALUES ('myValues')
--step 3
UPDATE a
SET rating=AVG(someValues)
FROM myTable a
JOIN otherTable b
ON a.column1=b.column1
GROUP BY someColumns
COMMIT TRANSACTION
The update statement on the problem server is the only step that takes
forever. While it is running, I don't see anything that could be
blocking the statement. I used the following queries to determine if
there was another process blocking it:
select spid AS Blocked, blocked AS Blocking, waittime, cmd, substring
(nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where blocked <> 0
order by waittime desc
select dbid, name from sysdatabases where dbid in (select dbid from
master.dbo.sysprocesses where blocked <> 0)
select spid AS BlockingFromAbove, blocked AS TrueBlockingQuery,
waittime, cmd, substring (nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where spid in (select blocked from
master.dbo.sysprocesses where blocked <> 0)
order by waittime desc
When I change the UPDATE statement to a SELECT, it still takes longer
than it does on the test server (1 min 35 sec vs. several
milliseconds).
What could be causing the UPDATE to take forever on one server/
database, and run without a problem on another?
I am at a loss! Any help would be greatly appreciated.Same execution plans on both server?
Also, when you say "data is exactly the same", does that mean whole database is identical, to the
point that one is a backup or attach of the other? If not, things like statistics can cause
different execution plans.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Baby Dragon" <nienna.gaia@.gmail.com> wrote in message
news:1177442708.864293.299400@.o40g2000prh.googlegroups.com...
> Hi!
> I have a stored procedure that takes 22 minutes to run in one
> environment, that only takes 1 sec or so to run in another
> environment. Here is the exact situation:
> Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
> exactly the same, and the tables and index structures are exactly the
> same. Implicit transactions are turned off on both databases.
> Stored procedure:
> BEGIN TRANSACTION
> --step 1
> TRUNCATE myTable
> --step 2
> INSERT INTO myTable VALUES ('myValues')
> --step 3
> UPDATE a
> SET rating=AVG(someValues)
> FROM myTable a
> JOIN otherTable b
> ON a.column1=b.column1
> GROUP BY someColumns
> COMMIT TRANSACTION
> The update statement on the problem server is the only step that takes
> forever. While it is running, I don't see anything that could be
> blocking the statement. I used the following queries to determine if
> there was another process blocking it:
> select spid AS Blocked, blocked AS Blocking, waittime, cmd, substring
> (nt_username, 1, 15), dbid, physical_io,
> substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
> memusage
> from master.dbo.sysprocesses where blocked <> 0
> order by waittime desc
> select dbid, name from sysdatabases where dbid in (select dbid from
> master.dbo.sysprocesses where blocked <> 0)
> select spid AS BlockingFromAbove, blocked AS TrueBlockingQuery,
> waittime, cmd, substring (nt_username, 1, 15), dbid, physical_io,
> substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
> memusage
> from master.dbo.sysprocesses where spid in (select blocked from
> master.dbo.sysprocesses where blocked <> 0)
> order by waittime desc
> When I change the UPDATE statement to a SELECT, it still takes longer
> than it does on the test server (1 min 35 sec vs. several
> milliseconds).
> What could be causing the UPDATE to take forever on one server/
> database, and run without a problem on another?
> I am at a loss! Any help would be greatly appreciated.
>|||I will take a look at the execution plans and any statistics that are
captured.
Thanks!

Different UPDATE behaviors across servers

Hi!

I have a stored procedure that takes 22 minutes to run in one
environment, that only takes 1 sec or so to run in another
environment. Here is the exact situation:

Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
exactly the same, and the tables and index structures are exactly the
same. Implicit transactions are turned off on both databases.

Stored procedure:

BEGIN TRANSACTION

--step 1
TRUNCATE myTable

--step 2
INSERT INTO myTable VALUES ('myValues')

--step 3
UPDATE a
SET rating=AVG(someValues)
FROM myTable a
JOIN otherTable b
ON a.column1=b.column1
GROUP BY someColumns

COMMIT TRANSACTION

The update statement on the problem server is the only step that takes
forever. While it is running, I don't see anything that could be
blocking the statement. I used the following queries to determine if
there was another process blocking it:

select spid AS Blocked, blocked AS Blocking, waittime, cmd, substring
(nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where blocked <0
order by waittime desc

select dbid, name from sysdatabases where dbid in (select dbid from
master.dbo.sysprocesses where blocked <0)

select spid AS BlockingFromAbove, blocked AS TrueBlockingQuery,
waittime, cmd, substring (nt_username, 1, 15), dbid, physical_io,
substring(hostname, 1, 15), program_name, lastwaittype, waitresource,
memusage
from master.dbo.sysprocesses where spid in (select blocked from
master.dbo.sysprocesses where blocked <0)
order by waittime desc

When I change the UPDATE statement to a SELECT, it still takes longer
than it does on the test server (1 min 35 sec vs. several
milliseconds).

What could be causing the UPDATE to take forever on one server/
database, and run without a problem on another?

I am at a loss! Any help would be greatly appreciated.Dmitri (nienna.gaia@.gmail.com) writes:

Quote:

Originally Posted by

I have a stored procedure that takes 22 minutes to run in one
environment, that only takes 1 sec or so to run in another
environment. Here is the exact situation:
>
Database 1 on Server 1 vs. Database 2 on Server 2 - the data is
exactly the same, and the tables and index structures are exactly the
same. Implicit transactions are turned off on both databases.


Apparently the query plans are different. This could be because there
are differences in statistics between the databases. Fragmentation
could also matter. I would recommend that you run DBCC DBREINDEX on
the tables in both environments. If you are lucky, the query runs
quickly in both databases. If you are less lucky, the query will now
run slowly in both databases.

If the machines has a different number of processors, this could also
matter. Maybe one machine is a single-CPU machine, whereas the other
is an 8-way box, so there is a parallel plan on server and a non-parallel
plan on the other. Parallel plans are sometimes really amazing -
either amazingly fast or amazingly slow.

Quote:

Originally Posted by

--step 3
UPDATE a
SET rating=AVG(someValues)
FROM myTable a
JOIN otherTable b
ON a.column1=b.column1
GROUP BY someColumns


Not that it matters for the discussion since I don't see the table
definition and the indexes, but this syntax is not legal.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Different Unicode Collation

I'm trying to combine 2 sql servers (7.0) to 1 sql server
(2000). However, the 2 sql servers have two different
unicode collations:
One Server:
SQL Server's Unicode collation is:
'English' (ID = 1033).
Second server:
SQL Server's Unicode collation is:
'English' (ID = 2057).
Is it possible to combine them into 1 SQL Server (2000).
Currently, these SQL Servers are in version 7.
Thanks.Please see my response to the duplicate post in this group under the
heading "2 Different Unicode Collation".
Thanks,
Bart
--
Please reply to the newsgroup only - thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.
Content-Class: urn:content-classes:message
From: "RG DBA" <anonymous@.discussions.microsoft.com>
Sender: "RG DBA" <anonymous@.discussions.microsoft.com>
Subject: Different Unicode Collation
Date: Thu, 13 Nov 2003 12:05:02 -0800
Lines: 19
Message-ID: <031801c3aa21$6c537f80$a301280a@.phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Thread-Index: AcOqIWxT5Y91hikTQE+u6lPJPIvlRw==Newsgroups: microsoft.public.sqlserver.server
Path: cpmsftngxa06.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.sqlserver.server:316413
NNTP-Posting-Host: TK2MSFTNGXA11 10.40.1.163
X-Tomcat-NG: microsoft.public.sqlserver.server
I'm trying to combine 2 sql servers (7.0) to 1 sql server
(2000). However, the 2 sql servers have two different
unicode collations:
One Server:
SQL Server's Unicode collation is:
'English' (ID = 1033).
Second server:
SQL Server's Unicode collation is:
'English' (ID = 2057).
Is it possible to combine them into 1 SQL Server (2000).
Currently, these SQL Servers are in version 7.
Thanks.

Wednesday, March 7, 2012

Different Service Pack

Hello Group,
has anyone experinced problems with replication between SQL servers on
different service packs? I have a customer I am setting up a replication for
that has a SQL Server 2000 on SP4 and another on SP3. I want them to upgrade
the SP3 one but they are not going to do it because they are waiting on some
hardware. Once the hardware gets here, they are going to dump all the 2000
and go to 2005.
In the meantime, they do not want to change anything...just get a
replication going between these two servers. Should just do it? Have you
seen any problems with this?
rich
There are occasionally errors with MDAC incompatibilities. Also sometimes
the sp does not seem to apply completely.
RelevantNoise.com - dedicated to mining blogs for business intelligence.
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
"Rich" <Rich@.discussions.microsoft.com> wrote in message
news:D46C5011-5447-44A2-82EE-F19B402CFF2D@.microsoft.com...
> Hello Group,
> has anyone experinced problems with replication between SQL servers on
> different service packs? I have a customer I am setting up a replication
> for
> that has a SQL Server 2000 on SP4 and another on SP3. I want them to
> upgrade
> the SP3 one but they are not going to do it because they are waiting on
> some
> hardware. Once the hardware gets here, they are going to dump all the
> 2000
> and go to 2005.
> In the meantime, they do not want to change anything...just get a
> replication going between these two servers. Should just do it? Have you
> seen any problems with this?
> rich

Friday, February 24, 2012

Different domains

Hi, I have two SQL servers in different domains(A and B), I cant use
the Enterprise Manager to register eachother...they show me "Sever doesnt exist" but when I use ping I can show them...
Please help me....What can I do?
cedutang.check out this link (http://www.dbforums.com/t968239.html) and see if it helps

Different Default Date format for 2 SQL Server Instances

Hi,
We recently had a new environment created. The servers were all installed
as separate instances on the same physical machine.
For my first instance INST1
When I execute the following query exec getMyData '1964-11-19'
in query analyser everything is fine
from my (ASP) website everything is fine
For my second instance INST2
in query analyser everything is fine
from my asp website I get varchar cannot be converted to datetime.
I can only believe that the default settings for the server were different
when each of the SQL Server Installs were performed.
I cannot change the way we pass dates in our website because it is a massive
re-write of everytihg if I do.
Is there some why of changing the default settings of the server after
installing?
I have tried using
sp_configure
SET language
sp_defaultlanguage
and all these methods did not fix my problem.
Any ideas?
JayneK wrote:
> Hi,
> We recently had a new environment created. The servers were all
> installed as separate instances on the same physical machine.
> For my first instance INST1
> When I execute the following query exec getMyData '1964-11-19'
> in query analyser everything is fine
> from my (ASP) website everything is fine
> For my second instance INST2
> in query analyser everything is fine
> from my asp website I get varchar cannot be converted to datetime.
> I can only believe that the default settings for the server were
> different when each of the SQL Server Installs were performed.
> I cannot change the way we pass dates in our website because it is a
> massive re-write of everytihg if I do.
> Is there some why of changing the default settings of the server after
> installing?
> I have tried using
> sp_configure
> SET language
> sp_defaultlanguage
> and all these methods did not fix my problem.
> Any ideas?
When working with dates in character format, you should only ever use a
portable format. Two formats are supported that will never cause
problems related to the server's regional settings:
yyyy-mm-ddThh:mm:ss.mmm (no spaces)
yyyymmdd
What is probably occurring is that one server is using MDY format and
the other is using DMY.
For example:
SET NOCOUNT ON
SET DATEFORMAT MDY
SELECT CAST('1964-11-19' as DATETIME)
SET DATEFORMAT DMY
SELECT CAST('1964-11-19' as DATETIME)
-- Results
1964-11-19 00:00:00.000
Server: Msg 242, Level 16, State 3, Line 9
The conversion of a char data type to a datetime data type resulted in
an out-of-range datetime value.
David Gugick - SQL Server MVP
Quest Software
|||David,
Unfortunately they all have all their language setting exactly the same. So
they are all set to us_english as default language, yet one server acts
differently to the other.
How can we fix this? do we have to uninstall and re-install, can't we hack
a file or something?
"David Gugick" wrote:

> JayneK wrote:
> When working with dates in character format, you should only ever use a
> portable format. Two formats are supported that will never cause
> problems related to the server's regional settings:
> yyyy-mm-ddThh:mm:ss.mmm (no spaces)
> yyyymmdd
>
> What is probably occurring is that one server is using MDY format and
> the other is using DMY.
> For example:
> SET NOCOUNT ON
> SET DATEFORMAT MDY
> SELECT CAST('1964-11-19' as DATETIME)
> SET DATEFORMAT DMY
> SELECT CAST('1964-11-19' as DATETIME)
> -- Results
> 1964-11-19 00:00:00.000
> Server: Msg 242, Level 16, State 3, Line 9
> The conversion of a char data type to a datetime data type resulted in
> an out-of-range datetime value.
>
>
> --
> David Gugick - SQL Server MVP
> Quest Software
>
|||JayneK wrote:[vbcol=seagreen]
> David,
> Unfortunately they all have all their language setting exactly the
> same. So they are all set to us_english as default language, yet one
> server acts differently to the other.
> How can we fix this? do we have to uninstall and re-install, can't
> we hack a file or something?
> "David Gugick" wrote:
The ASP web site client is likely set up different. Go to that PC, open
up QA, and run the example above. The problem is that you are not using
a portable date format and are bound to run into these types of
problems. If you get rid of the hyphens in the date parameter, that will
probably fix the issue. Since you cannot easily change the code
executing the date procedure you wrote, why not just change the
procedure itself to strip the hyphens out using Set @.MyDate =
REPLACE(@.MyDate, '-', '')
David Gugick - SQL Server MVP
Quest Software

Sunday, February 19, 2012

Different Collation designator Settings

Greetings,
In our company we have different kinds of SQL databases and SQL servers. We
are trying to consolidate those servers under a couple of powerful servers.
But when we began to tell this project to software houses and ask their
idea; we met a big problem .
Some of those companies are using SQL databases with Collation Designator =
Latin1_General setting. But the majority is using with Collation Designator
= Turkish setting. We want to consolidate them under a big MS SQL Server
2000. Anybody that we asked said that is impossible to consolidate those
databases under a server.
So my questions are ;
1- Is is really impossible to consolidate SQL dbases with different
character sets under a single server ? (Latin1_General + Turkish )
2- If no, how should I setup this MS SQL Server to support those char.sets ?
I will be very happy if anybody can help me .
Best regards.
Shadowfax
Hi Shadow,
You can have databases (and even columns) with different collations on SQL
Server 2000. That wasn't possible on SQL Server 7.
Whether it is going to work with 3rd party application is uncertain though.
The problem is that temporary tables are created with the collation of
tempdb on your server. And unless the 3rd party applications are good
quality code (which unfortunately is quite unlikely), there is a good chance
that they will compare character values in permanent tables with character
values in temporary tables while assuming that tempdb has the same collation
as the database that application uses. And if that is not the case, you will
get collation conflicts.
This can be avoided by specifying COLLATE DATABASE_DEFAULT with each
character column when creating temporary tables so that the default
collation of the database the user is currently connected to is used. But as
I said earlier, applications very rarely get up to this level of code
quality.
You would probably best off to have 2 servers, one with Latin1_General
collation and one with Turkish collation.
Jacco Schalkwijk
SQL Server MVP
"Shadow" <shadowfaxx001@.hotmail.com> wrote in message
news:ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl...
> Greetings,
> In our company we have different kinds of SQL databases and SQL servers.
> We are trying to consolidate those servers under a couple of powerful
> servers. But when we began to tell this project to software houses and ask
> their idea; we met a big problem .
> Some of those companies are using SQL databases with Collation Designator
> = Latin1_General setting. But the majority is using with Collation
> Designator = Turkish setting. We want to consolidate them under a big MS
> SQL Server 2000. Anybody that we asked said that is impossible to
> consolidate those databases under a server.
> So my questions are ;
> 1- Is is really impossible to consolidate SQL dbases with different
> character sets under a single server ? (Latin1_General + Turkish )
> 2- If no, how should I setup this MS SQL Server to support those char.sets
> ?
> I will be very happy if anybody can help me .
> Best regards.
> Shadowfax
>
>
|||Thanks for your help Jacco.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid > wrote
in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
> Hi Shadow,
> You can have databases (and even columns) with different collations on SQL
> Server 2000. That wasn't possible on SQL Server 7.
>
|||You could also consider having two instances of SQL (one w/Latin1_General,
the other with Turkish collation) on the same server.
Bart
Bart Duncan
Microsoft SQL Server Support
Please reply to the newsgroup only - thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Shadow" <shadowfaxx001@.hotmail.com>
| References: <ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl>
<#EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl>
| Subject: Re: Different Collation designator Settings
| Date: Tue, 25 Jan 2005 07:09:04 +0200
| Lines: 11
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Response
| Message-ID: <#Slv$vpAFHA.1392@.tk2msftngp13.phx.gbl>
| Newsgroups:
microsoft.public.sqlserver.connect,microsoft.publi c.sqlserver.odbc,microsoft
.public.sqlserver.server,microsoft.public.sqlserve r.setup
| NNTP-Posting-Host: dsl85-97-7802.ttnet.net.tr 85.97.30.122
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFT NGP08.phx.gbl!tk2msftngp13
.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.odbc:43188
microsoft.public.sqlserver.server:375538
microsoft.public.sqlserver.setup:68919
microsoft.public.sqlserver.connect:44240
| X-Tomcat-NG: microsoft.public.sqlserver.odbc
|
| Thanks for your help Jacco.
|
| "Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid >
wrote
| in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
| > Hi Shadow,
| >
| > You can have databases (and even columns) with different collations on
SQL
| > Server 2000. That wasn't possible on SQL Server 7.
| >
|
|
|

Different Collation designator Settings

Greetings,
In our company we have different kinds of SQL databases and SQL servers. We
are trying to consolidate those servers under a couple of powerful servers.
But when we began to tell this project to software houses and ask their
idea; we met a big problem .
Some of those companies are using SQL databases with Collation Designator =
Latin1_General setting. But the majority is using with Collation Designator
= Turkish setting. We want to consolidate them under a big MS SQL Server
2000. Anybody that we asked said that is impossible to consolidate those
databases under a server.
So my questions are ;
1- Is is really impossible to consolidate SQL dbases with different
character sets under a single server ? (Latin1_General + Turkish )
2- If no, how should I setup this MS SQL Server to support those char.sets ?
I will be very happy if anybody can help me .
Best regards.
Shadowfax
Hi Shadow,
You can have databases (and even columns) with different collations on SQL
Server 2000. That wasn't possible on SQL Server 7.
Whether it is going to work with 3rd party application is uncertain though.
The problem is that temporary tables are created with the collation of
tempdb on your server. And unless the 3rd party applications are good
quality code (which unfortunately is quite unlikely), there is a good chance
that they will compare character values in permanent tables with character
values in temporary tables while assuming that tempdb has the same collation
as the database that application uses. And if that is not the case, you will
get collation conflicts.
This can be avoided by specifying COLLATE DATABASE_DEFAULT with each
character column when creating temporary tables so that the default
collation of the database the user is currently connected to is used. But as
I said earlier, applications very rarely get up to this level of code
quality.
You would probably best off to have 2 servers, one with Latin1_General
collation and one with Turkish collation.
Jacco Schalkwijk
SQL Server MVP
"Shadow" <shadowfaxx001@.hotmail.com> wrote in message
news:ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl...
> Greetings,
> In our company we have different kinds of SQL databases and SQL servers.
> We are trying to consolidate those servers under a couple of powerful
> servers. But when we began to tell this project to software houses and ask
> their idea; we met a big problem .
> Some of those companies are using SQL databases with Collation Designator
> = Latin1_General setting. But the majority is using with Collation
> Designator = Turkish setting. We want to consolidate them under a big MS
> SQL Server 2000. Anybody that we asked said that is impossible to
> consolidate those databases under a server.
> So my questions are ;
> 1- Is is really impossible to consolidate SQL dbases with different
> character sets under a single server ? (Latin1_General + Turkish )
> 2- If no, how should I setup this MS SQL Server to support those char.sets
> ?
> I will be very happy if anybody can help me .
> Best regards.
> Shadowfax
>
>
|||Thanks for your help Jacco.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid > wrote
in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
> Hi Shadow,
> You can have databases (and even columns) with different collations on SQL
> Server 2000. That wasn't possible on SQL Server 7.
>
|||You could also consider having two instances of SQL (one w/Latin1_General,
the other with Turkish collation) on the same server.
Bart Duncan
Microsoft SQL Server Support
Please reply to the newsgroup only - thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Shadow" <shadowfaxx001@.hotmail.com>
| References: <ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl>
<#EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl>
| Subject: Re: Different Collation designator Settings
| Date: Tue, 25 Jan 2005 07:09:04 +0200
| Lines: 11
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Response
| Message-ID: <#Slv$vpAFHA.1392@.tk2msftngp13.phx.gbl>
| Newsgroups:
microsoft.public.sqlserver.connect,microsoft.publi c.sqlserver.odbc,microsoft
public.sqlserver.server,microsoft.public.sqlserver .setup
| NNTP-Posting-Host: dsl85-97-7802.ttnet.net.tr 85.97.30.122
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFT NGP08.phx.gbl!tk2msftngp13
phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.odbc:43188
microsoft.public.sqlserver.server:375538
microsoft.public.sqlserver.setup:68919
microsoft.public.sqlserver.connect:44240
| X-Tomcat-NG: microsoft.public.sqlserver.connect
|
| Thanks for your help Jacco.
|
| "Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid >
wrote
| in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
| > Hi Shadow,
| >
| > You can have databases (and even columns) with different collations on
SQL
| > Server 2000. That wasn't possible on SQL Server 7.
| >
|
|
|

Different Collation designator Settings

Greetings,
In our company we have different kinds of SQL databases and SQL servers. We
are trying to consolidate those servers under a couple of powerful servers.
But when we began to tell this project to software houses and ask their
idea; we met a big problem .
Some of those companies are using SQL databases with Collation Designator = Latin1_General setting. But the majority is using with Collation Designator
= Turkish setting. We want to consolidate them under a big MS SQL Server
2000. Anybody that we asked said that is impossible to consolidate those
databases under a server.
So my questions are ;
1- Is is really impossible to consolidate SQL dbases with different
character sets under a single server ? (Latin1_General + Turkish )
2- If no, how should I setup this MS SQL Server to support those char.sets ?
I will be very happy if anybody can help me .
Best regards.
ShadowfaxHi Shadow,
You can have databases (and even columns) with different collations on SQL
Server 2000. That wasn't possible on SQL Server 7.
Whether it is going to work with 3rd party application is uncertain though.
The problem is that temporary tables are created with the collation of
tempdb on your server. And unless the 3rd party applications are good
quality code (which unfortunately is quite unlikely), there is a good chance
that they will compare character values in permanent tables with character
values in temporary tables while assuming that tempdb has the same collation
as the database that application uses. And if that is not the case, you will
get collation conflicts.
This can be avoided by specifying COLLATE DATABASE_DEFAULT with each
character column when creating temporary tables so that the default
collation of the database the user is currently connected to is used. But as
I said earlier, applications very rarely get up to this level of code
quality.
You would probably best off to have 2 servers, one with Latin1_General
collation and one with Turkish collation.
--
Jacco Schalkwijk
SQL Server MVP
"Shadow" <shadowfaxx001@.hotmail.com> wrote in message
news:ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl...
> Greetings,
> In our company we have different kinds of SQL databases and SQL servers.
> We are trying to consolidate those servers under a couple of powerful
> servers. But when we began to tell this project to software houses and ask
> their idea; we met a big problem .
> Some of those companies are using SQL databases with Collation Designator
> = Latin1_General setting. But the majority is using with Collation
> Designator = Turkish setting. We want to consolidate them under a big MS
> SQL Server 2000. Anybody that we asked said that is impossible to
> consolidate those databases under a server.
> So my questions are ;
> 1- Is is really impossible to consolidate SQL dbases with different
> character sets under a single server ? (Latin1_General + Turkish )
> 2- If no, how should I setup this MS SQL Server to support those char.sets
> ?
> I will be very happy if anybody can help me .
> Best regards.
> Shadowfax
>
>|||Thanks for your help Jacco.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid> wrote
in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
> Hi Shadow,
> You can have databases (and even columns) with different collations on SQL
> Server 2000. That wasn't possible on SQL Server 7.
>|||You could also consider having two instances of SQL (one w/Latin1_General,
the other with Turkish collation) on the same server.
--
Bart Duncan
Microsoft SQL Server Support
Please reply to the newsgroup only - thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Shadow" <shadowfaxx001@.hotmail.com>
| References: <ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl>
<#EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl>
| Subject: Re: Different Collation designator Settings
| Date: Tue, 25 Jan 2005 07:09:04 +0200
| Lines: 11
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Response
| Message-ID: <#Slv$vpAFHA.1392@.tk2msftngp13.phx.gbl>
| Newsgroups:
microsoft.public.sqlserver.connect,microsoft.public.sqlserver.odbc,microsoft
public.sqlserver.server,microsoft.public.sqlserver.setup
| NNTP-Posting-Host: dsl85-97-7802.ttnet.net.tr 85.97.30.122
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13
phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.odbc:43188
microsoft.public.sqlserver.server:375538
microsoft.public.sqlserver.setup:68919
microsoft.public.sqlserver.connect:44240
| X-Tomcat-NG: microsoft.public.sqlserver.server
|
| Thanks for your help Jacco.
|
| "Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid>
wrote
| in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
| > Hi Shadow,
| >
| > You can have databases (and even columns) with different collations on
SQL
| > Server 2000. That wasn't possible on SQL Server 7.
| >
|
|
|

Different Collation designator Settings

Greetings,
In our company we have different kinds of SQL databases and SQL servers. We
are trying to consolidate those servers under a couple of powerful servers.
But when we began to tell this project to software houses and ask their
idea; we met a big problem .
Some of those companies are using SQL databases with Collation Designator =
Latin1_General setting. But the majority is using with Collation Designator
= Turkish setting. We want to consolidate them under a big MS SQL Server
2000. Anybody that we asked said that is impossible to consolidate those
databases under a server.
So my questions are ;
1- Is is really impossible to consolidate SQL dbases with different
character sets under a single server ? (Latin1_General + Turkish )
2- If no, how should I setup this MS SQL Server to support those char.sets ?
I will be very happy if anybody can help me .
Best regards.
ShadowfaxHi Shadow,
You can have databases (and even columns) with different collations on SQL
Server 2000. That wasn't possible on SQL Server 7.
Whether it is going to work with 3rd party application is uncertain though.
The problem is that temporary tables are created with the collation of
tempdb on your server. And unless the 3rd party applications are good
quality code (which unfortunately is quite unlikely), there is a good chance
that they will compare character values in permanent tables with character
values in temporary tables while assuming that tempdb has the same collation
as the database that application uses. And if that is not the case, you will
get collation conflicts.
This can be avoided by specifying COLLATE DATABASE_DEFAULT with each
character column when creating temporary tables so that the default
collation of the database the user is currently connected to is used. But as
I said earlier, applications very rarely get up to this level of code
quality.
You would probably best off to have 2 servers, one with Latin1_General
collation and one with Turkish collation.
Jacco Schalkwijk
SQL Server MVP
"Shadow" <shadowfaxx001@.hotmail.com> wrote in message
news:ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl...
> Greetings,
> In our company we have different kinds of SQL databases and SQL servers.
> We are trying to consolidate those servers under a couple of powerful
> servers. But when we began to tell this project to software houses and ask
> their idea; we met a big problem .
> Some of those companies are using SQL databases with Collation Designator
> = Latin1_General setting. But the majority is using with Collation
> Designator = Turkish setting. We want to consolidate them under a big MS
> SQL Server 2000. Anybody that we asked said that is impossible to
> consolidate those databases under a server.
> So my questions are ;
> 1- Is is really impossible to consolidate SQL dbases with different
> character sets under a single server ? (Latin1_General + Turkish )
> 2- If no, how should I setup this MS SQL Server to support those char.sets
> ?
> I will be very happy if anybody can help me .
> Best regards.
> Shadowfax
>
>|||Thanks for your help Jacco.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid> wrote
in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
> Hi Shadow,
> You can have databases (and even columns) with different collations on SQL
> Server 2000. That wasn't possible on SQL Server 7.
>|||You could also consider having two instances of SQL (one w/Latin1_General,
the other with Turkish collation) on the same server.
Bart Duncan
Microsoft SQL Server Support
Please reply to the newsgroup only - thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Shadow" <shadowfaxx001@.hotmail.com>
| References: <ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl>
<#EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl>
| Subject: Re: Different Collation designator Settings
| Date: Tue, 25 Jan 2005 07:09:04 +0200
| Lines: 11
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Response
| Message-ID: <#Slv$vpAFHA.1392@.tk2msftngp13.phx.gbl>
| Newsgroups:
microsoft.public.sqlserver.connect,microsoft.public.sqlserver.odbc,microsoft
public.sqlserver.server,microsoft.public.sqlserver.setup
| NNTP-Posting-Host: dsl85-97-7802.ttnet.net.tr 85.97.30.122
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13
phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.odbc:43188
microsoft.public.sqlserver.server:375538
microsoft.public.sqlserver.setup:68919
microsoft.public.sqlserver.connect:44240
| X-Tomcat-NG: microsoft.public.sqlserver.server
|
| Thanks for your help Jacco.
|
| "Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid>
wrote
| in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
| > Hi Shadow,
| >
| > You can have databases (and even columns) with different collations on
SQL
| > Server 2000. That wasn't possible on SQL Server 7.
| >
|
|
|

Different Collation designator Settings

Greetings,
In our company we have different kinds of SQL databases and SQL servers. We
are trying to consolidate those servers under a couple of powerful servers.
But when we began to tell this project to software houses and ask their
idea; we met a big problem .
Some of those companies are using SQL databases with Collation Designator =
Latin1_General setting. But the majority is using with Collation Designator
= Turkish setting. We want to consolidate them under a big MS SQL Server
2000. Anybody that we asked said that is impossible to consolidate those
databases under a server.
So my questions are ;
1- Is is really impossible to consolidate SQL dbases with different
character sets under a single server ? (Latin1_General + Turkish )
2- If no, how should I setup this MS SQL Server to support those char.sets ?
I will be very happy if anybody can help me .
Best regards.
Shadowfax
Hi Shadow,
You can have databases (and even columns) with different collations on SQL
Server 2000. That wasn't possible on SQL Server 7.
Whether it is going to work with 3rd party application is uncertain though.
The problem is that temporary tables are created with the collation of
tempdb on your server. And unless the 3rd party applications are good
quality code (which unfortunately is quite unlikely), there is a good chance
that they will compare character values in permanent tables with character
values in temporary tables while assuming that tempdb has the same collation
as the database that application uses. And if that is not the case, you will
get collation conflicts.
This can be avoided by specifying COLLATE DATABASE_DEFAULT with each
character column when creating temporary tables so that the default
collation of the database the user is currently connected to is used. But as
I said earlier, applications very rarely get up to this level of code
quality.
You would probably best off to have 2 servers, one with Latin1_General
collation and one with Turkish collation.
Jacco Schalkwijk
SQL Server MVP
"Shadow" <shadowfaxx001@.hotmail.com> wrote in message
news:ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl...
> Greetings,
> In our company we have different kinds of SQL databases and SQL servers.
> We are trying to consolidate those servers under a couple of powerful
> servers. But when we began to tell this project to software houses and ask
> their idea; we met a big problem .
> Some of those companies are using SQL databases with Collation Designator
> = Latin1_General setting. But the majority is using with Collation
> Designator = Turkish setting. We want to consolidate them under a big MS
> SQL Server 2000. Anybody that we asked said that is impossible to
> consolidate those databases under a server.
> So my questions are ;
> 1- Is is really impossible to consolidate SQL dbases with different
> character sets under a single server ? (Latin1_General + Turkish )
> 2- If no, how should I setup this MS SQL Server to support those char.sets
> ?
> I will be very happy if anybody can help me .
> Best regards.
> Shadowfax
>
>
|||Thanks for your help Jacco.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid > wrote
in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
> Hi Shadow,
> You can have databases (and even columns) with different collations on SQL
> Server 2000. That wasn't possible on SQL Server 7.
>
|||You could also consider having two instances of SQL (one w/Latin1_General,
the other with Turkish collation) on the same server.
Bart Duncan
Microsoft SQL Server Support
Please reply to the newsgroup only - thanks.
This posting is provided "AS IS" with no warranties, and confers no rights.
| From: "Shadow" <shadowfaxx001@.hotmail.com>
| References: <ePhKpPlAFHA.2112@.TK2MSFTNGP14.phx.gbl>
<#EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl>
| Subject: Re: Different Collation designator Settings
| Date: Tue, 25 Jan 2005 07:09:04 +0200
| Lines: 11
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Response
| Message-ID: <#Slv$vpAFHA.1392@.tk2msftngp13.phx.gbl>
| Newsgroups:
microsoft.public.sqlserver.connect,microsoft.publi c.sqlserver.odbc,microsoft
public.sqlserver.server,microsoft.public.sqlserver .setup
| NNTP-Posting-Host: dsl85-97-7802.ttnet.net.tr 85.97.30.122
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFT NGP08.phx.gbl!tk2msftngp13
phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.odbc:43188
microsoft.public.sqlserver.server:375538
microsoft.public.sqlserver.setup:68919
microsoft.public.sqlserver.connect:44240
| X-Tomcat-NG: microsoft.public.sqlserver.server
|
| Thanks for your help Jacco.
|
| "Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid >
wrote
| in message news:%23EJi6DmAFHA.2428@.TK2MSFTNGP14.phx.gbl...
| > Hi Shadow,
| >
| > You can have databases (and even columns) with different collations on
SQL
| > Server 2000. That wasn't possible on SQL Server 7.
| >
|
|
|

Friday, February 17, 2012

Different behaviours on different servers

I have a database and an application in .net using it.
In that database I have a stored procedure where is an import mechaism using
ODBC driver [Microsoft Text Driver (*.txt; *.csv)] and a .csv file.

On my machine everything works fine, but on the other machine import fails
with an exception

Could not execute query against OLE DB provider 'MSDASQL'.
[OLE/DB provider returned message: [Microsoft][ODBC Text Driver] Too few
parameters. Expected 6.]

My query looks like that:

DECLARE @.TSQL varchar(8000)

SET @.TSQL = 'INSERT INTO TABLE ( col1, col2, col3 )
SELECT * FROM OPENROWSET(''MSDASQL'', ''Driver={Microsoft Text Driver
(*.txt; *.csv)};DefaultDir='+@.import_dir_path+';'', ''select COL1, COL2,
COL3 from '+@.filename+''')'

EXEC (@.TSQL)
SELECT @.Err = @.@.ERROR, @.Rct = @.@.ROWCOUNT

Second error I get:
My location is Polish but my national chars do not pass through other ODBC
driver - for dbf s.
Database was simply detached and atached, so collation hasn't changed.

First machine (the good one) works under WinNTWkst4.0 Polish version with
SP6 and ODBC Drivers version 4.00.5303

Second machine (the bad one) works under Win2kServer Eng with MDAC 2.7.
ODBC Drivers version 4.00.4200.

If anyone can help me - please do that! I'm frustrated to the limit
already...

Regards,
Sliver"S" <sliver_1@.poczta.onet.pl> wrote in message
news:capbr5$jj4$1@.nemesis.news.tpi.pl...
> I have a database and an application in .net using it.
> In that database I have a stored procedure where is an import mechaism
using
> ODBC driver [Microsoft Text Driver (*.txt; *.csv)] and a .csv file.
> On my machine everything works fine, but on the other machine import fails
> with an exception
> Could not execute query against OLE DB provider 'MSDASQL'.
> [OLE/DB provider returned message: [Microsoft][ODBC Text Driver] Too few
> parameters. Expected 6.]
> My query looks like that:
> DECLARE @.TSQL varchar(8000)
> SET @.TSQL = 'INSERT INTO TABLE ( col1, col2, col3 )
> SELECT * FROM OPENROWSET(''MSDASQL'', ''Driver={Microsoft Text Driver
> (*.txt; *.csv)};DefaultDir='+@.import_dir_path+';'', ''select COL1, COL2,
> COL3 from '+@.filename+''')'
> EXEC (@.TSQL)
> SELECT @.Err = @.@.ERROR, @.Rct = @.@.ROWCOUNT
>
> Second error I get:
> My location is Polish but my national chars do not pass through other ODBC
> driver - for dbf s.
> Database was simply detached and atached, so collation hasn't changed.
> First machine (the good one) works under WinNTWkst4.0 Polish version with
> SP6 and ODBC Drivers version 4.00.5303
> Second machine (the bad one) works under Win2kServer Eng with MDAC 2.7.
> ODBC Drivers version 4.00.4200.
>
> If anyone can help me - please do that! I'm frustrated to the limit
> already...
> Regards,
> Sliver

I don't really have a good answer, but one possible issue is that the ODBC
drivers are different versions, and the one which doesn't work seems to be
older, so you might want to install the latest MDAC drivers (2.8, I think),
to see if that helps.

As an alternative, you could try using the Jet driver instead:

http://www.users.drew.edu/skass/sql/TextDriver.htm

Simon|||> I don't really have a good answer, but one possible issue is that the ODBC
> drivers are different versions, and the one which doesn't work seems to be
> older, so you might want to install the latest MDAC drivers (2.8, I
think),
> to see if that helps.

Thanks for answer - but it doesn't seams to be because of different vers. of
ODBC drvs - I've been so desperated that I installed on the fresh machine
win2kSrv with a 2kEnt database, set a patch on it and then mdac 2.8 - but
between all changes I'd been verifing if my query works. Laugh if you want
to - it was working even on fresh db - without any upgrade - and hadn't stop
after upgrades had been set up.
ODBC drivers versions are now the same as on the bad one machine ...

So - I have no idea what can be wrong. Is there anything like national
versions of ODBC drivers?

> As an alternative, you could try using the Jet driver instead:
> http://www.users.drew.edu/skass/sql/TextDriver.htm

It is good idea - but remember of the second problem - chars of my national
my charset aren't served properly... and the files are dbf... I have them
done through a linked server - but still the ODBC driver seems to be a
failure...

S.|||Just a hunch, but I would keep looking down the route of MDAC. We had
a problem with insufficient parameters a while back. From what I
remember later versions of MDAC included an additional parameter to
the connection string when opening a database through an ODBC
connection. It would store this depending on the PC which created the
connection. We found this with a DTS package.

We could create a connection within a DTS package and then use in on
another server (ran as scheduled) which had a lower version which
would then not run. You may be able to test by re-creating the
connection on the version with the lower version so it doesn't include
this additional parameter and it may work. If it does, then I would
suggest a version issue which needs addressing.

As I say, it's a hunch as it's a little while since I looked at it,
but it may be of help to you.

We upgraded each PC and server to the same version of MDAC (2.8) to
get rid or the problem.

HTH

Ryan

Differencies in triggers behavior on 2000 and 2005 SQL Servers

This code works fine on MS SQL 2000 but fails on MS SQL 2005:

create database tt

go

--exec dbo.sp_dbcmptlevel @.dbname=N'tt', @.new_cmptlevel=80

go

use tt
go

create table t (id int)
go

create proc p as update t set id=id
go

create trigger t1_i on t instead of update as update t set id=id
go

create trigger t1 on t for update as if @.@.nestlevel > 5 return exec p update t set id=id
go

insert t select 1
go

update t set id=id
go

use master
go
drop database tt
go

Using database compatibility level 80 (SQL 2000, uncomment the line starting with --exec dbo.sp_dbcmptlevel...) does not make this code work like it does on SQL 2000!

We have examined this code and found that changing

create trigger t1 on t for update as if @.@.nestlevel > 5 return
exec p -- this procedure just executes "update t set id=id" and fails

to direct "update"

create trigger t1 on t for update as if @.@.nestlevel > 5 return
update t set id=id -- works fine without any errors

makes this code work fine but our procedure p is too complex to do any workarounds...

With which error does the procedure fail ?

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

Msg 570, Level 16, State 1, Procedure p, Line 2

Instead of triggers do not support direct recursion. Trigger execution failed.

|||Hi,

do you have another triggers defined on the table ?

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

There are no other triggers. That code (in the first message) is enough complete to reproduce the error.

Sestrin

|||I believe this has been submitted to MS Connect, http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=248294 and awaiting workaround.