The Problem: One of our stored procedures was using CHARINDEX to search for strings within the database. The problem appeared when a user defined a search parameter containing a trailing space and the results of the search were not as expected.

SQL and Trailing Blanks

(From the section “Comparison operators, listed” in SQL help)

Trailing blanks are ignored in comparisons; for example, these are equivalent:

WHERE LastName = 'White'
WHERE LastName = 'White '
WHERE LastName = 'White' + SPACE(1)

This is an interesting article: INF: How SQL Server Compares Strings with Trailing Spaces

Sort of related but actually about how data is stored is the ANSI_PADDING setting:

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

Display Trailing Space in Clarion

The Clarion entry control and text control don’t appear to be able to show trailing spaces from data in a database. You can enter trailing spaces in an entry or text control and save the data but next time you view or edit the form those trailing spaces are not shown.

Funnily enough, if the data does have trailing spaces and the field is not edited then the trailing spaces remain intact when the form is saved.

Fun with SELECT Statements

Have a play with the following SQL to see some examples:

Note the use of “LIKE” rather than “=” and the “[^ ]” will force the WHERE to only match items without the trailing space.
Also, try setting the ANSI_PADDING to “OFF” and see the difference in the results.

SET ANSI_PADDING ON;
CREATE TABLE t1 (charcol CHAR(16) NULL, varcharcol VARCHAR(16) NULL)
INSERT INTO t1 VALUES ('No blanks', 'No blanks');
INSERT INTO t1 VALUES ('Trailing blank ', 'Trailing blank ');
 
SELECT * FROM t1 WHERE varcharcol LIKE 'No blanks     '
SELECT * FROM t1 WHERE charcol LIKE 'No blanks     '
 
SELECT * FROM t1 WHERE varcharcol LIKE 'Trailing blank[^ ]'
SELECT * FROM t1 WHERE charcol LIKE 'Trailing blank[^ ]'
 
DROP TABLE t1

So there are a few thoughts and discoveries that came up in the course of investigating this issue. Of course once you know the reasons there are ways to workaround the problems but I will leave that up to your individual scenario…

Problem:

I was getting an error “There is already an object named ‘PK_SUPPLIERPRODUCTID’ in the database.” when trying to create a temp table.

Scenario:

• A temp table (’#Temp’ & Thread()) was created initially in a window procedure on thread 2.
• That window was then closed and later opened on a different thread number e.g. 3.
• When the CREATE TABLE is called the second time I was getting the above error.

Original SQL:

1

CREATE TABLE #Temp (SUPPLIERPRODUCTID int NOT NULL CONSTRAINT PK_SUPPLIERPRODUCTID PRIMARY KEY)

Gotcha’s:

• Normally the details of a temp table are “session” dependent. It seems that because I was explicitly naming the primary key (PK_SUPPLIERPRODUCTID) this was somehow bypassing the way temp tables are assigned session unique names.
• Scope of SQL temp tables:
  • “All other local temporary tables are dropped automatically at the end of the current session.”
  • I had always thought that a “session” would mean the Clarion Thread connection.
    • It kinda does and kinda doesn’t.
    • Temp tables are assigned uniqueness based on the clarion thread connection but they are not removed from the database when the clarion thread closes.
    • They are only actually dropped from the SQL tempdb when the clarion application closes!

Solutions:

• Don’t explicitly name the primary key! This works without error:

  1	CREATE TABLE #Temp (SUPPLIERPRODUCTID int PRIMARY KEY)

• If you do a “CREATE TABLE” then try and make sure to do a “DROP TABLE” once you are done (perhaps as well as before the create?).
  • This has the added benefit of keeping the tempdb cleaner.
  • I guess this is just basic house keeping like in clarion when you must always New/Dispose.

Disclaimer: I don’t claim to be an SQL expert, these are my observations and my solutions. I would love to hear any comments!