By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,302 Members | 1,788 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,302 IT Pros & Developers. It's quick & easy.

Character set translation / tp performance

P: n/a
Hi,

I have a problem regarding the perfomance of a stp in combination with
character translation.

The following happens.
We have an automated installation script (nt command file) for
creating all stored procedures in a database.

At first we used osql in this script, but with osql the international
characters (, etc) were not entered correctly into the database.
The tip given in some newsgroups was to use isql in stead of osql, and
turn off automatic ansi to oem translation.
This worked perfectly. However now some stored procedures are executed
much slower than before (and they take up much cpu). When I drop and
recreate the stored procedure using Query Analyser, the performance
goes up again.

When I look through the messages in this group, the advise is to use
osql instead of isql. But I just changed to isql because of the
character translation!

Does anyone have a solution for this?
Jul 20 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
You might try including SET QUOTED_IDENTIFIER ON and SET ANSI_NULLS ON
at the beginning of your script file. QA (which uses ODBC) sets these
options on by default and this may result in a different execution plan.

Regarding ISQL, you might consider saving your file in Unicode format
and using OSQL instead. You can then use the OSQL -I command line
parameter to turn on the QUOTED_IDENTIFIER option.

--
Hope this helps.

Dan Guzman
SQL Server MVP

-----------------------
SQL FAQ links (courtesy Neil Pike):

http://www.ntfaq.com/Articles/Index....partmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
-----------------------

"Dick Zeeman" <mi***********@hotmail.com> wrote in message
news:fa**************************@posting.google.c om...
Hi,

I have a problem regarding the perfomance of a stp in combination with
character translation.

The following happens.
We have an automated installation script (nt command file) for
creating all stored procedures in a database.

At first we used osql in this script, but with osql the international
characters (, etc) were not entered correctly into the database.
The tip given in some newsgroups was to use isql in stead of osql, and
turn off automatic ansi to oem translation.
This worked perfectly. However now some stored procedures are executed
much slower than before (and they take up much cpu). When I drop and
recreate the stored procedure using Query Analyser, the performance
goes up again.

When I look through the messages in this group, the advise is to use
osql instead of isql. But I just changed to isql because of the
character translation!

Does anyone have a solution for this?

Jul 20 '05 #2

P: n/a
[posted and mailed, please reply in news]

Dick Zeeman (mi***********@hotmail.com) writes:
I have a problem regarding the perfomance of a stp in combination with
character translation.

The following happens.
We have an automated installation script (nt command file) for
creating all stored procedures in a database.

At first we used osql in this script, but with osql the international
characters (, etc) were not entered correctly into the database.
The tip given in some newsgroups was to use isql in stead of osql, and
turn off automatic ansi to oem translation.
This worked perfectly. However now some stored procedures are executed
much slower than before (and they take up much cpu). When I drop and
recreate the stored procedure using Query Analyser, the performance
goes up again.

When I look through the messages in this group, the advise is to use
osql instead of isql. But I just changed to isql because of the
character translation!


Dan's reply gave the answer you needed to get things working. I'll only
add some explanation to this.

With ISQL, all SET options are off. With Query Analyzer, a couple are on
by default. The ones that Dan mentioned, ANSI_NULLS and QUOTED_IDENTIFIER
are particularly important, because the setting at compile time is
saved with the procedures.

I don't think that QUOTED_IDENTIFIER can affect the query plan for
queries in general. ANSI_NULLS could in theory, although I don't know
how common this is. However, there are two cases where these settings
are essential, and that is when you have queries that involves indexed
computed columns and indexed views. For these indexes to be used, these
two settings must be ON. This is the most likely reason why you saw
such a drastic difference in execution. It is also therefore Dan tipped
you to use -I with OSQL.

I should also add that queries that involves linked queries requires
ANSI_NULLS to be on.

Finally, I should add to Dan's reply that you can use QA to save files
in Unicode format. You can actually even save in OEM format from QA,
if you like.

--
Erland Sommarskog, SQL Server MVP, so****@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #3

P: n/a
Dan and Erland thanks for you reaction.

We will try saving all scripts in oem format.
Unicode is not an option, since we use SourceSafe and SS does not like
unicode files.

Regards

Dick Zeeman
Jul 20 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.