显示标签为“padding”的博文。显示所有博文
显示标签为“padding”的博文。显示所有博文

2012年2月9日星期四

ANSI PADDING OFF not working

Hi,

I have set ANSI PADDING off by default for the database but even then when I create any table ANSI PADDING is on.

While creation of table I am able to set it off before I create it and then create the table with correct settings. But when I am altering the table it is always off even when I am setting specifically before altering the table.

Any ideas how to make this work?

Thanks.

The SQL Server ODBC driver and OLEDB provider sets several SET options ON by default. And ANSI_PADDING is one of those. So it deosn't matter if you switch it OFF at the database level. Any connection made by one of the data access API will automatically have ANSI_PADDING ON. I am curious as to why you want to set it to OFF. It is recommended to use the ANSI settings by default since lot of features depend on it (like computed column indexes, indexed view matching etc) and it is also compatible with other databases like DB2/Oracle. See the topics below for more details:

SET ANSI_PADDING topic

http://msdn2.microsoft.com/en-us/library/ms187403.aspx

SET ANSI_DEFAULTS topic

http://msdn2.microsoft.com/en-us/library/ms188340.aspx

Btw, the only way is to modify your application code to set ANSI_PADDING off after making the connection. This also means that if you need to work with the schema in OSQL or ISQLW or SSMS for example you need to do the same because they all use OLEDB/ODBC/ADO.NET to make connection to SQL Server. So it is actually easier to get into trouble not using the defaults. Note that in the future we may remove the SET options and consider making the ANSI settings default.

|||If ANSI Padding is on is stored with spaces and we do not want that.|||

I am not sure if there is a question in your response. If you want to use ANSI_PADDING OFF on the server-side then you need to enable in explicitly after connection. This is the only way due to the reasons I described before. Best is to trim values before it reaches the database server on the client-side.

Additionally, you need to be aware of recompilation of SPs/statements that access tables with ANSI_PADDING off and the session setting is different. So please be aware of all these limitations in addition to other missing enterprise features (computed column matching, indexed views matching etc). See the link below for the how batch compilation, recompilation etc works and how the SET options are used:

http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx

|||

I can give you reasons NEVER to have padding on. Any tables you create will have a hidden padding on setting so that you can no longer control padding with set, ODBC, ADO or even database level switches. But more importantly, features such as the like clause with the underscore pattern match will return incorrect results on any of these “damaged” tables.

Eg. Select fred where fred like ‘123__’

Will return results of:

123

123A

123AB

It should only return 123AB. <null> should not be a character. Time consuming bugs like these are the reason I would recommend never setting padding on and I hope you seriously consider defaulting to padding off in future. It's by far the more useful setting.

ANSI PADDING OFF not working

Hi,

I have set ANSI PADDING off by default for the database but even then when I create any table ANSI PADDING is on.

While creation of table I am able to set it off before I create it and then create the table with correct settings. But when I am altering the table it is always off even when I am setting specifically before altering the table.

Any ideas how to make this work?

Thanks.

The SQL Server ODBC driver and OLEDB provider sets several SET options ON by default. And ANSI_PADDING is one of those. So it deosn't matter if you switch it OFF at the database level. Any connection made by one of the data access API will automatically have ANSI_PADDING ON. I am curious as to why you want to set it to OFF. It is recommended to use the ANSI settings by default since lot of features depend on it (like computed column indexes, indexed view matching etc) and it is also compatible with other databases like DB2/Oracle. See the topics below for more details:

SET ANSI_PADDING topic

http://msdn2.microsoft.com/en-us/library/ms187403.aspx

SET ANSI_DEFAULTS topic

http://msdn2.microsoft.com/en-us/library/ms188340.aspx

Btw, the only way is to modify your application code to set ANSI_PADDING off after making the connection. This also means that if you need to work with the schema in OSQL or ISQLW or SSMS for example you need to do the same because they all use OLEDB/ODBC/ADO.NET to make connection to SQL Server. So it is actually easier to get into trouble not using the defaults. Note that in the future we may remove the SET options and consider making the ANSI settings default.

|||If ANSI Padding is on is stored with spaces and we do not want that.|||

I am not sure if there is a question in your response. If you want to use ANSI_PADDING OFF on the server-side then you need to enable in explicitly after connection. This is the only way due to the reasons I described before. Best is to trim values before it reaches the database server on the client-side.

Additionally, you need to be aware of recompilation of SPs/statements that access tables with ANSI_PADDING off and the session setting is different. So please be aware of all these limitations in addition to other missing enterprise features (computed column matching, indexed views matching etc). See the link below for the how batch compilation, recompilation etc works and how the SET options are used:

http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx

|||

I can give you reasons NEVER to have padding on. Any tables you create will have a hidden padding on setting so that you can no longer control padding with set, ODBC, ADO or even database level switches. But more importantly, features such as the like clause with the underscore pattern match will return incorrect results on any of these “damaged” tables.

Eg. Select fred where fred like ‘123__’

Will return results of:

123

123A

123AB

It should only return 123AB. <null> should not be a character. Time consuming bugs like these are the reason I would recommend never setting padding on and I hope you seriously consider defaulting to padding off in future. It's by far the more useful setting.

ANSI PADDING OFF not working

Hi,

I have set ANSI PADDING off by default for the database but even then when I create any table ANSI PADDING is on.

While creation of table I am able to set it off before I create it and then create the table with correct settings. But when I am altering the table it is always off even when I am setting specifically before altering the table.

Any ideas how to make this work?

Thanks.

The SQL Server ODBC driver and OLEDB provider sets several SET options ON by default. And ANSI_PADDING is one of those. So it deosn't matter if you switch it OFF at the database level. Any connection made by one of the data access API will automatically have ANSI_PADDING ON. I am curious as to why you want to set it to OFF. It is recommended to use the ANSI settings by default since lot of features depend on it (like computed column indexes, indexed view matching etc) and it is also compatible with other databases like DB2/Oracle. See the topics below for more details:

SET ANSI_PADDING topic

http://msdn2.microsoft.com/en-us/library/ms187403.aspx

SET ANSI_DEFAULTS topic

http://msdn2.microsoft.com/en-us/library/ms188340.aspx

Btw, the only way is to modify your application code to set ANSI_PADDING off after making the connection. This also means that if you need to work with the schema in OSQL or ISQLW or SSMS for example you need to do the same because they all use OLEDB/ODBC/ADO.NET to make connection to SQL Server. So it is actually easier to get into trouble not using the defaults. Note that in the future we may remove the SET options and consider making the ANSI settings default.

|||If ANSI Padding is on is stored with spaces and we do not want that.|||

I am not sure if there is a question in your response. If you want to use ANSI_PADDING OFF on the server-side then you need to enable in explicitly after connection. This is the only way due to the reasons I described before. Best is to trim values before it reaches the database server on the client-side.

Additionally, you need to be aware of recompilation of SPs/statements that access tables with ANSI_PADDING off and the session setting is different. So please be aware of all these limitations in addition to other missing enterprise features (computed column matching, indexed views matching etc). See the link below for the how batch compilation, recompilation etc works and how the SET options are used:

http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx

|||

I can give you reasons NEVER to have padding on. Any tables you create will have a hidden padding on setting so that you can no longer control padding with set, ODBC, ADO or even database level switches. But more importantly, features such as the like clause with the underscore pattern match will return incorrect results on any of these “damaged” tables.

Eg. Select fred where fred like ‘123__’

Will return results of:

123

123A

123AB

It should only return 123AB. <null> should not be a character. Time consuming bugs like these are the reason I would recommend never setting padding on and I hope you seriously consider defaulting to padding off in future. It's by far the more useful setting.

ansi padding issues 64 bit vs 32 bit

Hi all.

I'm using the SQL 2005 partitioning schemes to keep 5 weeks worth of data in a table, swapping in a new week and getting rid of the old week. It works fantastic in a 32 bit environment, when I try it in a 64 bit Itanium cluster, I start having issues with the schema's (specifically the ANSI PADDING) being different between my partitioned table and my "Archive" table, the one that I'm switching the old data out to.

When I created the partitioned table originally, I didn't specify ansi padding at all, so my assumption would be that it would take the default of the database, which is "false". However, when you execute a script in Mgt Studio, the default setting is to have ANSI Padding ON. That's fine, so now my tables are all set to ANSI Padding On when I created them, but the database setting is Off, I can live with that. So how come when I run my SSIS Package in a 32 bit environment, which calls 2 stored procedures to do the partitions switching (inside the 2 stored procedures I have dynamic "Create Table" statements for both the New Week and Archive tables, in order to get them on the proper file groups), these Create table statements apparently create the tables with ANSI Padding set to ON as well, because I don't have a problem. But when I use the exact same SSIS Package with the exact same Stored Procedures in the 64 bit environment, I get the following error?

Error: ALTER TABLE SWITCH statement failed because column 'VendorNum' does not have the same ansi trimming semantics in tables 'ODSTJM.dbo.WeeklyActivityCumulative' and 'ODSTJM.dbo.WeeklyActivityCumulativeArchive'.(42000,50000) Procedure(usp_WACPartitionForArchive), Batch 10 Line 188

If I right click either the New or Archive tables (that are dynamically generated) in Mgt Studio and generate script, these 2 tables both Have the ANSI PADDING set to OFF? Every other table is set to ON. Again, this issue doesn't happen in 32 bit, only 64 bit. Any ideas?

Please help.

Andy

This actually ended up being an issue with DBArtisan. By default, dbArtisan has ansi padding set to off, while SQL 2005 has it set to on in Mgt Studio, which was causing the problem. Lesson learned, don't run from dbArtisan.

ANSI Padding

How can one find out the ANSI Padding setting (i.e. ON or
OFF) of an existing table without drawing a conclusion
from playing with the data in the subject table?sp_help <table>
look at the column "trimtrailingblanks"
if trimtrailingblanks = yes --ansi padding off
if truntraukubgblanks = no --ansi padding on
--
- Vishal|||oops, spelling mistake ,
if trimtrailingblanks = yes --ansi padding off
if trimtrailingblanks = no --ansi padding on
--
- Vishal|||In addition to what Vishal said, you can use the
UsesAnsiTrim COLUMNPROPERTY. Notice that it is not a table
property, but a column property. Try:
SET ANSI_PADDING ON
create table Test (col1 varchar(10))
SET ANSI_PADDING OFF
alter table Test add col2 varchar(10)
select COLUMNPROPERTY(OBJECT_ID('Test'), 'col1',
N'UsesAnsiTrim')
select COLUMNPROPERTY(OBJECT_ID('Test'), 'col2',
N'UsesAnsiTrim')
drop table Test
HTH
Vern
>--Original Message--
>How can one find out the ANSI Padding setting (i.e. ON or
>OFF) of an existing table without drawing a conclusion
>from playing with the data in the subject table?
>.
>

ANSI Nulls SQL Server Setting

Should I be using the SQL Server 2000 ANSI warnings, ANSI padding, ANSI null
s
since I'm using the ANSI-92 joins in my T-SQL statements?
What effect will this have on database performance with this disable?
What reason should you have that SQL Server ANSI warnings, ANSI padding,
ANSI nulls are turn off?
Please help me with these answer?
Thank You,ANSI_NULLS, ANSI_PADDING and ANSI_WARNINGS are not needed to use ANSI-92
joins.
The most important of these to consider in your queries is ANSI_NULLS, which
defines the behavior when comparing null values. But this is important even
if you are using ANSI-92 joins or not.
See 'Setting Database Options' on SQL Server 2000 BOL for more information.
Ben Nevarez
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:D9C612A2-4B76-4A13-A226-D85BDC2C1422@.microsoft.com...
> Should I be using the SQL Server 2000 ANSI warnings, ANSI padding, ANSI
> nulls
> since I'm using the ANSI-92 joins in my T-SQL statements?
> What effect will this have on database performance with this disable?
> What reason should you have that SQL Server ANSI warnings, ANSI padding,
> ANSI nulls are turn off?
> Please help me with these answer?
> Thank You,

ANSI Nulls SQL Server Setting

Should I be using the SQL Server 2000 ANSI warnings, ANSI padding, ANSI nulls
since I'm using the ANSI-92 joins in my T-SQL statements?
What effect will this have on database performance with this disable?
What reason should you have that SQL Server ANSI warnings, ANSI padding,
ANSI nulls are turn off?
Please help me with these answer?
Thank You,
ANSI_NULLS, ANSI_PADDING and ANSI_WARNINGS are not needed to use ANSI-92
joins.
The most important of these to consider in your queries is ANSI_NULLS, which
defines the behavior when comparing null values. But this is important even
if you are using ANSI-92 joins or not.
See 'Setting Database Options' on SQL Server 2000 BOL for more information.
Ben Nevarez
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:D9C612A2-4B76-4A13-A226-D85BDC2C1422@.microsoft.com...
> Should I be using the SQL Server 2000 ANSI warnings, ANSI padding, ANSI
> nulls
> since I'm using the ANSI-92 joins in my T-SQL statements?
> What effect will this have on database performance with this disable?
> What reason should you have that SQL Server ANSI warnings, ANSI padding,
> ANSI nulls are turn off?
> Please help me with these answer?
> Thank You,

ANSI Nulls SQL Server Setting

Should I be using the SQL Server 2000 ANSI warnings, ANSI padding, ANSI nulls
since I'm using the ANSI-92 joins in my T-SQL statements?
What effect will this have on database performance with this disable?
What reason should you have that SQL Server ANSI warnings, ANSI padding,
ANSI nulls are turn off?
Please help me with these answer?
Thank You,ANSI_NULLS, ANSI_PADDING and ANSI_WARNINGS are not needed to use ANSI-92
joins.
The most important of these to consider in your queries is ANSI_NULLS, which
defines the behavior when comparing null values. But this is important even
if you are using ANSI-92 joins or not.
See 'Setting Database Options' on SQL Server 2000 BOL for more information.
Ben Nevarez
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:D9C612A2-4B76-4A13-A226-D85BDC2C1422@.microsoft.com...
> Should I be using the SQL Server 2000 ANSI warnings, ANSI padding, ANSI
> nulls
> since I'm using the ANSI-92 joins in my T-SQL statements?
> What effect will this have on database performance with this disable?
> What reason should you have that SQL Server ANSI warnings, ANSI padding,
> ANSI nulls are turn off?
> Please help me with these answer?
> Thank You,