User bio

IT Jack of all trades, developing and maintaining Mumps/Intersystems systems since the 90's.

Member since Apr 27, 2021
Posts:
Replies:

The delimiter should not matter as long as you handle quoting fields that contain the delimiter or quotes (making sure to double-quote inside a quoted field). 

It sounds like a faff but is not actually that difficult to code, for either output or input, and is a pretty standard way to handle CSV.  Also the class %SQL.Util.Procedures can be useful or there are some examples in Open Exchange.

I would also add making sure your migration is either restartable, from a point of failure, or can catch up on failed entries, after tweaking either the code or data.  You don't want to have to run the whole thing again and which  negation method you opt for depends on whether the data must be loaded in order or not.

IO can be a biggie, look at the IOPS and make sure any high values aren't just burst rates for a limited number of times a day.

Just realised this is an old(ish) post but it has had a recent response so I'll still add the below FWIW...

This is nice an simple but be aware it doesn't handle commas, or other potentially problematic characters, in a string value.

CSV requires that any value containing quotes or the delimiter (comma) should be quoted, anything that reads in CSV should handle this.

Given an example "one,2,three,4" your example works but """one,"",2,three,4"  will not, it will create a list with 5 parts.

set line = """one,"",2,three,4"
set fields = $ListFromString(line, ",")
for n = 1:1:$listlength(fields) w !,$list(fields,n)

"one
"
2
three
4

The %SQL.Util.Procedures class has some useful CSV methods or take a look at CSVGEN.
 

Open Exchange applications:
Certifications & Credly badges:
David has no Certifications & Credly badges yet.
Followers:
Following:
David has not followed anybody yet.