am exporting a query table to a CSV file and its all working ok but my only problem is that the Salary Field is showing two decimals after the export that i dont want,what i tried so far is
1- reformat the field in the query to loose the decimals like this
Amount: Format(Salary,"0")
when i run the query (inside Access) there are no decimals but after the export they are still there
2- remove the decimals from (Region and Language) in the control panel(i dont like this approach) and the result is that the Zeros are gone but the decimal point still there.
Try to convert to long
Amount: CLng(Salary)
It was a faulty Office app,re installing it fixed the problem.
Related
I have a SQL query that returns a value similar to "7 KI" for a description column, but when I export my data to a .csv/text file using SQLCMD, the resulting data is "7KI" (no space inbetween 7 and K). I believe that this causes a formatting issue when I open this csv file in Excel later on...(I'm wondering if "7K" is getting read as 7,000 because the data is splitting into a new column as-if it contained a comma there?)...
This is so weird to me. I am using the Quotename function to return the Unicode version of this description field in the first place - do you think that's why I am experiencing this issue? I used the Quotename function to fix issues with this field a few days ago. To me, it's odd that the export is stripping the space inbetween 7 and K in the first place.
Has anyone ever seen/fixed this before? It really looks like there is a space included in the SQL data, and I copied-and-pasted the value into a online Unicode converter to confirm there is a space. Why would a random space be getting stripped in the SQLCMD export? Plenty of my other text fields are not having this issue, even though they have spaces too (although not followed by "K"...) so maybe the issue is with CMD somehow reading the value...?
I have a table with one field that is made up of hyperlinks such as this:
<http://nl.dbpedia.org/resource/Wereldkampioenschappen_indooratletiek_2008>
Now I have to change the datatype of this field to shorttext so I can later use JOIN in the query. From what I understand it is supposed to automatically cut-off all lines that go above the 255 character threshold. This is not the case with the example above, however if I change the datatype to ShortText it changes that text to:
<http://nl.dbpedia.org/resource/Wereldkampioenschappen_in
So it seems to keep only 57 characters instead of 255. I also tried using the Import Text Wizard and putting the datatype as ShortText there (so it never gets imported as a hyperlink), but the same problem persists as when I change it from hyperlink to shorttext.
Does anyone know how I can fix this? Thanks :)
P.S. I literally started working with Access today, so I'm still very much Googling everything. I couldn't find this problem anywhere though unfortunately.
Short Text will truncate the text to the number of characters specified in the "Table Design" view. You can specify any number of characters from 1 to 255.
More Information:
YouTube : Access 2016: Getting Started
Office.com : Access Database design basics
Office.com : Introduction to data types and field properties
Office.com : Data types for Access desktop databases
I imported using fixed width instead of delimited. Use delimited and this problem goes away!
I use Workbench to query database at work. We have a field which indicates company size and has the following options :
1-9
10-49
50-99
100-499
500+
When I export the results containing this field in Excel(which I use for analysis), 1-9 becomes 9-Jan, when I change the format of the cell to text, it becomes 42013. Similarly, 10-49 becomes Oct-50 and in text - 18537. Is there a way to avoid this?
I know this may seem trivial but I take a download of the results every couple of hours or so, and currently, I use the Replace function in Excel to fix this which is a time cost. Also, adding manual intervention increases the probability of error which I want to minimize. I would ideally like the result to export as 1-9, as it exists in the database, based on which the analytical model is built to take input.
I would appreciate any help or pointers on how to fix this issue.
Thanks!
You are not saying how you are bringing the data into Excel. The simplest method is to bring the column in as "text". You can do this when you are importing the data into Excel, by setting the column type to "text".
Alternatively, when you create the output file, you can prepend the value with a single quote or some other character:
select concat('''', company_size)
select concat('_', company_size)
Appreciate the help! I used to export the results in CSV which caused the problem I think. I exported them in XML and that solved it, the fields appear as they exist in the database. Thanks a lot. The concatenation would work as well!
I have numeric data with have value 0.546, 0.456 in the database. When I try to export these values to flat file using flat file manager the zero value is truncated and only .546,.456 is shown in the flat file.
The value other than zero doesn't have this problem.
I tried using data conversion but of no use
Try Data Conversion transform - Data Type: decimal [DT-DECIMAL) : Scale 3.
Good find, Prakash!
I'm afraid you'll have to first convert you numeric data to DT_WSTR. It has to be Derived Column transformation, not Data Conversion, because you'd get the same result. In expression you need to prepend converted number with 0. Don't know about negative numbers, but maybe they will have correct format (you need to test it).
floor(decimal_column)==0 ? "0" + (DT_WSTR,10)decimal_column : (DT_WSTR,10)decimal_column
I know that's not what you expected, but I had the same problem the other day and was unable to finde better solution :).
I have a source flat file with values such as 24.209991, but they need to load to SQL Server as type money. In the DTS (which I am converting from), that value comes across as 24.21. How do I convert that field in SSIS?
Right now, I am just changing the type from DT_STR to DT_CY, and it gives a run error of 'Data conversion failed. The data conversion for column "Col003" returned status value 2 and status text "The value could not be converted because of a potential loss of data.".'
Do I use a Data Conversion task? And then what?
I've also tried setting the source output column to DT_NUMERIC, and then convert that to DT_CY, with the same result.
I've also tried using Derived Columns, casting the DT_STR field Col003 to (DT_NUMERIC,10,2)Col003 and then casting that to (DT_CY)Col003_Numeric. That's getting a cast error.
The flat file defaults to all fields being DT_STR. Use the Advanced option on editing the connection to have the numeric field as float (DT_R4). Then, in the advanced editing of the Flat File Source (on the Data Flow tab), set that output column to money (DT_CY).
Then, the field will convert without any additional conversions. The issue was leaving the source file definition as DT_STR.
If you don't have any null value use Data Conversion, and make sure you don't have any funny character (e.g. US$200 produce error)
If you have null or empty fields in your field and you are using Flat file source, make sure that you tick "Return null value from source.."
Another trick I have used is something like: (taxvalue != "" ? taxvalue : NULL(DT_WSTR,50)). in Derived Column transformation (you can just replace the field)
Generally SSIS doesn't convert empty strings to money properly.
For some reason in my scenario, the OLE DB Destination actually was configured to accept a DT_CY. However, casting to this format (no matter the length of the input and destination data, and no matter wether or not the data was NULL when it arrived) always caused the same issue.
After adding data viewers, I can conclude that this has something to do with the locale. Here in Denmark, we use comma (,) as decimal delimiters and dots (.) as thousands-delimiters, instead of the opposite.
This means that a huge number like 382,939,291,293.38 would (after the conversion to DT_CY) look like 382.939.291.293,38. Even though I highly doubted that it could be the issue, I decided to do the opposite of what I originally had intended.
I decided to go to the advanced settings of my OLE DB Destination and change the DT_CY column's type to DT_STR instead. Then, I added a Derived Column transformation, and entered the following expression to transform the column before the data would arrive at the destination.
REPLACE(SUBSTRING(Price, 2, 18), ",", ".") where Price was the column's name.
To my big surprise, this solved the problem, since I figured out that my OLE DB Destination was now sending the data as a string, which the SQL Server understood perfectly fine.
I am certain that this is a bug! I was using SQL Server 2008, so it might have been solved in later editions. However, I find it quite critical that such an essential thing is not working correctly!