Character set translation / tp performance

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?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...epartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--------

"Dick Zeeman" <minicontainer@.hotmail.com> wrote in message
news:fad166e1.0309010100.3464bf9e@.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?|||[posted and mailed, please reply in news]

Dick Zeeman (minicontainer@.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, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||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

char(1) vs smallint

I'm having a disagreement with a fellow developer regarding flags. I prefer to declare flag columns as smallint and apply a rule restricting the values to 1 or 0. He prefers to use a char(1) with a rule restricting the values to 'Y' or 'N'. Can anyone give me ammunition against the char(1) or tell me if I'm wrong. Oh yeah, the flag is cast to a boolean in the app written in java, if that makes a difference.Y/N is convenient if users will be querying the database directly, but if you are performing any aggregations then 1/0 allows you to more easily sum the number of flagged records. The percentage flagged, for instance, is just Sum(Flag)/Count(*). (Note that the BIT type won't work with most aggregate functions, otherwise it would be the boolean type of choice.)

You do need to be careful with 1/0 to make sure other applications interpret it correctly. Under some systems TRUE = -1 and FALSE = 0, and other situations are possible.

blindman|||Originally posted by peterlemonjello
I'm having a disagreement with a fellow developer regarding flags. I prefer to declare flag columns as smallint and apply a rule restricting the values to 1 or 0. He prefers to use a char(1) with a rule restricting the values to 'Y' or 'N'. Can anyone give me ammunition against the char(1) or tell me if I'm wrong. Oh yeah, the flag is cast to a boolean in the app written in java, if that makes a difference.
Usually developers know much more than dbas ;). I am using tinyint for flags.|||Thanx blindman and snail! Unfortunately, I'm a developer that new way too much about databases and sql server so I'm a dba now too. As a developer I always said the only thing worse than a dba is a object oriented developer turned dba, guess I'm eating my own words... LOL!!!|||actually, the only thing worse than a dba is a data architect or data modeller like me with years (decades, actually) of modelling and sql language experience, who couldn't solve a performance problem to save his life other than perhaps declaring the obvious indexes...

performance issues aside, you have to look at the implications of your design on the sql to solve business problems

blindman had a superb example -- sum(flag)/count(*)

that's the type of thing a modeller knows, that a dba might not

tinyint (or smallint) is also good because it's a lot more portable across database platforms than boolean

rudy
http://r937.com/|||Those with experience in small shops that required both development and admin duties know best! :D

...but I also think my experience in object-oriented development has helped me develop modular database applications. There is no such thing as bad experience, just people who can't see beyond their own particular project scope.

blindman