What is the purpose of adding a text qualifier to a SSIS flat text file output?
I'm pulling data out of a SQL database that has quotes/commas/pipes/and many other common delimiters in the data.
Extreme example of a data point in a column:
"Johnson"|Smith,Jones
I set up the export as a comma delimited, with a double quote " text qualifier. I assumed it would export the data like so, and it did:
,""Johnson"|Smith,Jones",
Now i'm testing re-importing the data back in, as a comma delimited, with a double quote text qualifier. I got errors saying SSIS couldn't find the delimiter. I thought it would recognize the combination comma, and double quote, essentially as a more complex delimiter.
If adding a text delimiter to the output doesn't help with the problem of having the characters in the actual data, what does it do?
Assuming the person receiving the data might use a tool like Excel to process the data, which doesn't seem to be able to handle a complex multi character delimiter like |", is the best way to handle this by removing the most common delimiter from my data, and using that as the delimiter? Probably pipe in my case, instead of comma.
Text qualifier is used in the event that delimiters are contained within the row cell. Typically, the text qualifier is a double quote. In the event that the cell contains a delimiter and a text qualifier is not used, then the data that occurs after the delimiter will spill into the next column. From there, the data row can potentially blow up and none of the columns will line up afterwards. It can be a real mess.
Additionally, you will not see the text qualifier in applications, like Excel. However, if you open the file in Notepad++, then you will see the text qualifiers. There can be a lot of data (e.g., text qualifiers, new line characters, column delimiters, etc.) that is contained within a file but is not displayed in certain applications. This data typically is used to define the structure of the data as opposed to being the actual data.
For your problem, you will need to remove the double quotes from the source data or use a different text qualifier. You could use a single quote, but what if you have data like Jones's? The idea here is that the text qualifier should be unique in defining the data structure, which, as I understand it, means that you cannot have a text qualifier that is actually a part of the data (see note from Microsoft below - emphasis mine).
Per Microsoft:
Specify a text qualifier character. Each column can be configured to
recognize a text qualifier.
The use of a qualifier character to embed a qualifier character into a
qualified string is supported by the Flat File Connection Manager. The
double instance of a text qualifier is interpreted as a literal,
single instance of that string. For example, if the text qualifier is
a single quote and the input data is 'abc', 'def', 'g'hi', the output
data is abc, def, g'hi. However, an instance of a qualifier embedded
in a qualified string causes the Flat File Source to fail with the
error DTS_E_PRIMEOUTPUTFAILED.
References
Flat File Connection Manager official documentation
Related
I am trying to work with an external vendor to my company that is sending a csv file that I need to import into various tables in our database. We have other vendors who send similar files and they always send csv files with quotation marks around every field (in case there are commas in the field). As such, I make the field terminator "," for the file, and it bulk inserts just fine since all fields will include this terminator.
The problem that I'm running into is that we have a new vendor that is unable to enclose every field in quotation marks. They are using RFC 4180, which includes quotation marks around fields that have commas, but it doesn't include quotation marks when there aren't commas. So, this leads to inconsistent field terminators when attempting to bulk insert, and I don't know of a way around it. If I make the field terminator a comma, it will split fields that have commas in them, but I similarly can't make the field terminator "," since that will not be around every field.
Any advice is welcome. I am trying to work with the vendor to send a consistent format, but, in case they can't, I'm trying to also find a workaround.
I'm dealing with a csv file that contains double inverted quotes (since the data has commas in it). But Google sheets do not show me the double-quotes and hence i'm able to split the column by a delimiter (space in this case) properly, to retrieve its first word. The initial column values can be seen in the picture below.
However, in Data Prep when i upload the csv file, the column's double quotes are considered as a value and it causes extra work (if at all possible) in handling the resulting split data.
Is there a way in Data Prep where we can have the data displayed as in Google Sheets ?
You can "ignore" these double-quotes, and when running a job, untick the box of "include quotes", then these original quotes shall remain.
Not perfect, but could be a working workaround.
Leading zeros not retaining while reading comma separated value(csv) file by Microsoft ACE Ole Db means if col value is 0000123456, i am getting only 123456 only, while reading programmatically in vb.net. i don't want to put any condition while preparing the comma separated value(csv) file i.e. used of apostrophe before the zeros etc.
Data structure is like below in comma separated value(csv) file
Name,ID
John,0001234
moon,0001235
but i am getting id as 1234 , 1235 but i want with zeros using Microsoft ACE Ole Db
Please guys any idea.Thanks in advance
The Text File driver used by OleDb to read CSV files is unable to accurately determine the datatype of the columns. In your case, your second column is misunderstood to be a numeric column because it contains only digits, thus the leading zero are removed.
You can give a strong hint to OleDb creating a file called SCHEMA.INI that explains what is the content of the file.
In your case you could create one in the same folder of the file (I assume temp.csv for this example) and write these lines:
[temp.csv]
Format=CSVDelimited
ColNameHeader=True
Col1=Name Text
Col2=ID Text
DecimalSymbol=.
Notice that I need to specify the DecimalSymbol being a point because in my locale the comma is used as separator between the decimal and the integer part of a number (thus we use CSV files separated by semicolons)
I've been given some csv files that I want to turn into tables in a SQL database. However, the genius who created the files used comma delimiters, even though several data fields contain commas. So when I try to BCP the data into the database, I get a whole bunch of errors.
Is there a way that I can escape the commas that aren't field separators? At the moment I'm tempted to write a script to manually replace every comma in each file with a pipe, and then go through and manually change the affected rows back.
The only way to fix this is to write a script or program that fixes the data.
If the bad data is limited to a single field the process should be trivial:
You consume the row from either side by the count of good delimiters and replace with a new unique delimiter and what remains is the column with the extra old delimiters that you would just leave as is.
If you have two bad fields straddling good fields, you would need some kind of advanced logic, for instance I had XML data with delimiters, I had to parse the XML until I found a terminating tag and then process the other delimiters as needed.
I have a text file that is split using commas
Simple enough to do in SSIS but i have the following row in my source flat file:
Desc,Curr,Desc,ID,Quantity
05969A105 ,CU,BANCORP INC, THE DEL COMMON ,1,2126
there is a comma in my Desc column and im not sure how i can ignore that comma
AFAIK, you can't do anything in SSIS (or any other app that I have ever used) to handle this, because it is simply bad data. If you need to persist with comma delimiters then you will need to get the data provider to use text-delimiters, e.g. double-quotes, to wrap the data. SSIS can be told what is the text delimiter and will strip these chars off the data automatically.
Of course this may raise the issue of 'but the text may need to contain a double-quote!', in which case you would be better off getting the delimiter changed to something else, such as a tab or pipe.