Diable auto-trim in SQL Server Management Studio Express 2008 - sql-server-2008
Several times when troubleshooting my SQL queries, I run into a problem where there is extra space in one of my columns which breaks a comparison. Because SSMS 2008 auto-trims those columns, I don't see the problem. It makes troubleshooting take much longer.
Is there any way to disable this auto-trimming?
I don't know of a way to do this through the SSMS options, but I discovered a workaround: it appears that SSMS does not autotrim if all values in the column are of a string type. For instance, the following will display with ten spaces in front of the numeric value:
select
space(10) + cast(2000 as varchar)
as PaddedValue
Without the cast, the spaces do not appear in the results grid:
select
space(10) + 2000
as TrimmedValue
Related
BCP CHAR value to Snowflake
I am trying to create a BCP file with | delimiter and then load it to a snowflake table. Issue: in SQL server there are columns defined as CHAR(4) and have values "sss" so when i do BCP the its being padded to length of 4 "sss " and being loaded to snowflake due to which our reports are failing because they do something like where column="SSS" but due to trailing space in snowflake the correct columns are not showing up. we do not want to change our reports. So, is there a way that BCP can handle the padding or trimming of these columns? note that there 24 tables and each have around 130+ columns so i cant go and put Trim functions on each char column
If your BCP file is maintaining the trailing space, then Snowflake will retain it, too, as long as the field is being FIELD_OPTIONALLY_ENCLOSED_BY a " or '. You may also want to make sure your TRIM_SPACE option is correctly set on your format definition for your COPY INTO command. If your BCP file isn't maintaining the space and you can't figure out how to get that to work, you could force the space back in during the COPY INTO command with some string functions in your SELECT, or you could create a view for your report that does the same set of string functions to force the space for your report to work from.
So, is there a way that BCP can handle the padding or trimming of these columns? Yes, but not by some switch or option. The correct way to handle this is to set your datatypes up front. As someone mentioned in comments to your question, your query that is creating BCP output should use VARCHAR(4) instead of CHAR(4). BCP is giving you what you asked of it. They way to avoid whitespace is to use varchar. Seems like a fairly quick "find and replace" against scripted out query objects would work fine but you know your situation best. Additionally, "trim" wont work - FYI. Even if the value of the field was only "SSS" (as in your example); if the result/column is defined as CHAR(4) you will get 4 bytes of data and a blank in the 4th place since you only had 3 bytes of data. Trim will work during the query... the padded " " you are getting is placed there by the copy out. The way to correct this is to set your data types as you need up front. Unless someone knows of a better way in snowflake (im not familiar with it) the only other option is to manipulate the file inbetween SQL and Snowflake. replace " |" with "|"... but... blech.
This is a known "issue" with BCP. The "solution" is to use the queryout option, which means you must include a query with every export. But the data are the way they are.
Eg: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/88c258fe-d1a6-4f3a-9dac-40388d04e9c7/remove-space-in-columns-on-bcp-out?forum=transactsql
But this is really a Snowflake problem, because Snowflake has its own default CHAR semantics.
You get a warning in the documentation String & Binary Data Types but that doesn't tell the whole truth.
The following executed on Oracle (and apparently MSSQL? MySQL?) will select the aaa line:
CREATE TABLE C AS SELECT CAST('aaa ' AS CHAR(4)) t FROM DUAL;
SELECT * FROM C WHERE t = 'aaa';
but won't on Snowflake, unless you create the column with COLLATION:
CREATE OR REPLACE TABLE C (t CHAR(4) COLLATE 'en_US-rtrim');
INSERT INTO C VALUES('aaa ');
SELECT * FROM C WHERE t = 'aaa';
Unfortunately, you can't ALTER the collation after creation, which would have been convenient after a COPY INTO <table>.
PS: Mike Walton's answer is better, TRIM_SPACE is much cleaner than COLLATE.
Syntax error in date in query expression for non-date fields
I'm having trouble building a query in Access 2013. The database isn't mine and the only thing I really have control over is this query. There is a table, I'm pulling 7 fields from it and eventually adding an 8th field to the query to do some string manipulation. However, I keep getting getting "Syntax error in date in query expression 'fieldname'." error whenever I click on the arrow to sort the fields. The odd thing is these errors pop up when sorting non-date fields. When sorting the date field I get "Syntax error (missing operator) in query expression 'Release Date'." This happens after a fresh build. I have no WHERE conditions, just SELECT and FROM. Ideas? Here's the sql query, though I'm mainly working in the query design view: SELECT Transmissions.[Job#], Transmissions.[Part#], Transmissions.TransmissionSN, Transmissions.Status, Transmissions.[Release Date], Transmissions.[Build Book Printed], Transmissions.[ID Tags Required] FROM Transmissions;
Well... it seems you are the lucky inheritor of a poorly designed database. Using special characters in a field name is just asking for trouble. And you've found what that trouble is. Access uses the # sign to designate a Date type for query comparisons. Such as: dtSomeDate = #2/20/2017# You surround the date with the # signs. In your case, the query thinks [Job#] and [Part#] are trying to wrap dates. But of course, that's not the case and thus it fails. You can try a couple of work arounds. (I leave it to you to experiment.) 1) You can try to rename the problem fields within your query. So that: Transmissions.[Job#] becomes Transmissions.[Job#] as JobNum and Transmissions.[Part#] becomes Transmissions.[Part#] as PartNum 2) You can try to copy the [Transmissions] table to a new table that you create that does not have the naming problems. 3) Export the [Transmissions] table to a CSV file and re-import it to a new table (or possibly new database) without the naming problems. Here is a link to a microsoft article that tells you why to avoid special characters in Access: Big Bad Special Chars. Hope that puts you on the right track. :)
Typically, this means that the field names are missing or misspelled. Try running this to see: SELECT * FROM Transmissions;
Removing leading zeros in SSIS
I process data from a legacy system with SSIS before importing data into a SQL Server 2008 db. A currency field is so formatted: 000000xxx.xx I need to remove the leading zeros. Note that the actual currency value has not a fixed number of digit. So, for instance, it could be xxxxx.xx or x.xx or xxxxxxxxxxx.xx I found this answer, but the derived column tool display only limited string functions, like the Access formula wizard. So my question: how may I use PATINDEX in the DTS derived column tool otherwise, how may I remove leading zeros from input column
how are you querying the data? I suppose you are using direct table access on your OleDBSource component, right? I do not advise that because a tiny change on the table may break your package. I would right a view containing the select from your source table and on this select I would use the PATINDEX function and inside the package, I would select the view instead of the table. This is a good approach because if you need to do a minor change, you can change the view instead of the package If you dont want to write a view, fine, instead of selecting "data access mode" = "table or view", select "sql command" and write your sql directly on the package.
Are you not able to cast the data into a numeric equivalent type in the source system? That should be a quick way to drop the leading zeros. SELECT CAST(myCurrency AS decimal(18,2)) AS leadingZerosDropped FROM myTable Otherwise, the dead simple SSIS way to do it is to use a Data Conversion task and cast it to a numeric type (DT_CY/Currency or DT_Numeric/Numeric worked just fine) Source query SELECT '000000111.11' AS stringCurrency UNION ALL SELECT '0.22' UNION ALL SELECT '03.33' UNION ALL SELECT '004.44' UNION ALL SELECT '0005.55' UNION ALL SELECT '00000000000000000006.66' Data Conversion transformation I created a new column, currencyCurrency which was the stringCurrency with a data type of currency [DT_CY] applied. Results stringCurrency currencyCurrency 000000111.11 111.11 0.22 0.22 03.33 3.33 004.44 4.44 0005.55 5.55 00000000000000000006.66 6.66 I fully support not using table access mode and in general I'm in favor of pushing work onto the source system but this seems like a low effort if the source system doesn't allow for conversion or if you have to resort to mucking about with strings.
Insert special characters into SQL Server 2008 database
The ' ' character cannot be included in a name. I use a log manager to log the error to SQL Server 2008 database. Of course, it will raise another error in the SQL Server because it contains special characters' ' . So what is the best way to handle special characters in SQL Server.
This is because you are using a space in an XML name. Correct your XML code to not have spaces in any tag names, this isn't SQL Server 2008 specific.
To get a column to handle special characters define it as a NVARCHAR instead of a VARCHAR.
Your question is a bit vague. Do you want to prevent the user from having a space? And if so, do you want to not allow there to be a space character, or just get the space character out? If so, do something like replace(#yourInputString, ' ', ''). If this is not what you are looking for, please clarify your question and your exact requirements.
issue with floating point when importing flat file comma separated SQL Server 2008
I have an issue while importing this dataset.txt (flat file, comma separated)in SQL Server 2008 x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15,x16,x17,x18,x19,x20,x21,x22,x23,x24,x25 0.438,0.498,3.625,3.645,5.000,2.918,5.000,2.351,2.332,2.643,1.698,1.687,1.698,1.717,1.744,0.593,0.502,0.493,0.504,0.445,0.431,0.444,0.440,0.429,1.0 0.438,0.498,3.625,3.648,5.000,2.918,5.000,2.637,2.332,2.649,1.695,1.687,1.695,1.720,1.744,0.592,0.502,0.493,0.504,0.449,0.431,0.444,0.443,0.429,1.0 0.438,0.498,3.625,3.629,5.000,2.918,5.000,2.637,2.334,2.643,1.696,1.687,1.695,1.717,1.744,0.593,0.502,0.493,0.504,0.449,0.431,0.444,0.446,0.429,1.0 0.437,0.501,3.625,3.626,5.000,2.918,5.000,2.353,2.334,2.642,1.730,1.687,1.695,1.717,1.744,0.593,0.502,0.493,0.504,0.449,0.431,0.444,0.444,0.429,1.0 0.438,0.498,3.626,3.629,5.000,2.918,5.000,2.640,2.334,2.639,1.696,1.687,1.695,1.717,1.744,0.592,0.502,0.493,0.504,0.449,0.431,0.444,0.441,0.429,1.0 0.439,0.498,3.626,3.629,5.000,2.918,5.000,2.633,2.334,2.645,1.705,1.686,1.694,1.719,1.744,0.589,0.502,0.493,0.504,0.446,0.431,0.444,0.444,0.430,1.0 0.440,5.000,3.627,3.628,5.000,2.919,3.028,2.346,2.330,2.638,1.727,1.684,1.692,1.714,1.745,0.588,0.501,0.492,0.504,0.451,0.433,0.446,0.444,0.432,1.0 0.444,5.021,3.631,3.634,5.000,2.919,5.000,2.626,2.327,2.638,1.698,1.680,1.688,1.709,1.740,0.595,0.500,0.491,0.503,0.453,0.436,0.448,0.444,0.436,1.0 0.451,5.025,3.635,3.639,5.000,2.920,3.027,2.620,2.323,2.632,1.706,1.673,1.681,1.703,0.753,0.595,0.499,0.491,0.502,0.457,0.440,0.453,0.454,0.442,2.0 0.458,5.022,3.640,3.644,5.000,2.922,5.000,2.346,2.321,2.628,1.688,1.666,1.674,1.696,0.744,0.590,0.496,0.490,0.498,0.462,0.444,0.458,0.461,0.449,2.0 0.465,0.525,3.646,3.670,5.000,2.923,5.000,2.611,2.315,2.631,1.674,1.658,1.666,1.688,0.735,0.593,0.495,0.488,0.497,0.467,0.449,0.462,0.469,0.457,2.0 0.473,0.533,3.652,3.676,5.000,2.925,5.000,2.607,2.310,2.623,1.669,1.651,1.659,1.684,0.729,0.578,0.496,0.487,0.498,0.469,0.454,0.467,0.476,0.465,2.0 0.481,0.544,3.658,3.678,5.000,2.926,5.000,2.606,2.303,2.619,1.668,1.643,1.651,1.275,0.723,0.581,0.495,0.486,0.497,0.477,0.459,0.472,0.484,0.472,2.0 0.484,0.544,3.661,3.665,5.000,2.928,5.000,2.321,2.304,5.022,1.647,1.639,1.646,1.270,0.757,0.623,0.493,0.484,0.495,0.480,0.461,0.474,0.485,0.476,2.0 0.484,0.532,3.669,3.662,2.945,2.926,5.000,2.326,2.306,2.620,1.648,1.639,1.646,1.270,0.760,0.533,0.493,0.483,0.494,0.507,0.461,0.473,0.486,0.476,2.0 0.482,0.520,3.685,3.664,2.952,2.927,5.000,2.981,2.307,2.329,1.650,1.640,1.644,1.268,0.757,0.533,0.492,0.482,0.492,0.513,0.459,0.474,0.485,0.474,2.0 0.481,0.522,3.682,3.661,2.955,2.927,2.957,2.984,1.700,2.622,1.651,1.641,1.645,1.272,0.761,0.530,0.492,0.482,0.492,0.513,0.462,0.486,0.483,0.473,2.0 0.480,0.525,3.694,3.664,2.948,2.926,2.950,2.995,1.697,2.619,1.651,1.642,1.646,1.269,0.762,0.530,0.493,0.482,0.492,0.516,0.462,0.486,0.483,0.473,2.0 0.481,0.515,5.018,3.664,2.956,2.927,2.947,2.993,1.697,2.622,1.651,1.641,1.645,1.269,0.765,0.592,0.489,0.482,0.495,0.531,0.462,0.499,0.483,0.473,2.0 I put the procedure I am following: So, if you can see, when selecting in SQL Server, the floating point desappears? Maybe I am doing something wrong, in the column type, I also tried real, but get the same result, Do i have to tell something else to SQL ?
One thing I did note is that you are doing something in Spanish not English. Do the Spanish use the , as the decimal separator (I know some countries do but don;t know which ones)?
In Advance options, could you set dataprecision/datascale and try it again? That might help. I'm not sure.
Change regional settings to USA and ensure decimal places . or , Change country too and select USA. Restart SQL Server Management and try it. It works for me in Spain!