errors within an exported .slk file

[Mike Fedkiw]

Well when I was trying to export my inventory file there were fields ending with a quote and that messed things up. If I'm remembering right, it would mess up the alignment of the cells that followed the quote. The quotes were within the description because it might have been for inches on a measurement. Anyway, no matter what I tried, I couldn't get it to export correctly and that's why I started using the slt file and I thought I was all set until the errors on the slt file when exporting a different files data 

Mike 

On Jul 22, 2014, "Brian K. White" <brian at aljex.com> wrote:
>On 7/20/2014 4:31 PM, Mike Fedkiw wrote:
>> Actually a CSV file is where I started with a different export but I
>just couldn't get it to work because of asterisks, commas and
>semicolons within the field I wanted to export. That's why I went to
>the SLK file, it didn't care about any of that. I think it's kinda
>ridiculous that it can be so difficult to export stuff like I'm trying
>to. It's like use slk for this one but use something different for
>another and I haven't really done much exporting anyway. Can't wait
>until I need to find a third way to export something, this just sucks.
>
>Welcome to computers? The problems involved with data handling are just
>
>part of the job.
>
>I have not had any problem exporting data from fp using csv, including 
>all of those characters and even newlines embedded within a single
>field 
>in a single record. Whatever field and record delimiters you choose, 
>those are the only characters you have to scan and delete or encode on 
>export. I usually do it with a little gosub, like
>
>n = 4 ; gosub clean ; out(4) = n
>
>Any other problems lie in the *receiver*. Some apps fail to import 
>perfectly valid data. If the thing doing the importing chokes on 
>asterisks, then I guess you have to add asterisk encoding into your 
>gosub clean. That's particular to that app you're importing to though. 
>It would be wrong for anything else. In that case instead of gosub
>clean 
>it should probably be called gosub make-app-foo-happy, except we can't 
>have labels that long ;)
>
>example:
>---top---
>...
>   If: 'notes
>Then: n=19{l{20{l{21{l{22{l{23{l{24{"" ; gosub clean ; csv(19)=n
>...
>clean  If:
>      Then: n = xlate(n,chr("34"){chr("13"),"'") ; return
>...
>If:
>Then: end
>@once If:
>     Then: l(1,*,g)=chr("10")
>...
>---bottom---
>
>So L is defined globally as a newline character in @once, happens just 
>once, first, before any record processing.
>
>Then during record processing, several fields and newlines are catted 
>together into N
>
>Then gosub clean only does two things in this case, it changes any " 
>into ' and it deletes any carriage returns, and the result is put back 
>into N
>
>Then the csv output gets that all into a single field in a single
>record.
>
>In this case the receiver was Palm Desktop and MS Outlook.
>In either app, when you pull up a contact that was exported this way, 
>one of the things in the address book entry was a notes field, which
>was 
>really an entire small text file with line-breaks within it. The data 
>was modified so any double-quotes were changed to single quotes, which 
>is not ideal, but no other characters had to be changed at all.
>
>A more proper answer is probably to double any double-quotes.
>I think that's what Excel and LibreOffice etc expect these days and so 
>it's probably what most other apps expect as well.
>
>So, instead of the above very crude gosub, it gets a little more 
>difficult, but only one time, then you can copy it after you have one 
>working example. The gosub needs to loop through the field one char at
>a 
>time unfortunately and build a new field in this case, because there is
>
>no fancy sed-like function in fp. If you want to to change any one 
>character to any one other char, or delete any character, no problem, 
>xlate() is simple. But if you want to replace any single character with
>
>a multiple character encoding, like changing $ to \$, for that you need
>
>to do it yourself with a loop. But, it's not that bad once you have one
>
>working example. And once it's in a gosub, it's no harder to use than a
>
>function. In this case, here's an example that changes " to "".
>
>legend:
>di = data in (do not declare a size for di)
>do = data out
>dp = data position
>dl = data length
>ic = input character
>oc = output character (do not declare a size for oc)
>q = a double-quote character
>n = i/o ( the only variable used to talk to the gosub )
>
>
>clean
>Then: dp = "1" ; do = "" ; q = chr("34")
>Then: di = n{"" ; dl = len(di)
>nxtchr
>Then: ic = mid(di,dp,"1") ; oc = ic
>   If: ic eq q
>Then: oc = q { q
>Then: do = do & oc
>   If: dp lt dl
>Then: dp = dp + "1" ; goto nxtchr
>Then: n = do ; return
>
>
>
>Use it the same way as before:
>
>Then: n = 4 ; gosub clean ; out(4) = n
>
>All this one does is, any " are turned into ""
>That should handle quotes within fields in csv for most spreadsheet 
>apps. The receiving app converts it back to a single "
>
>You would put any other tests & transformations you want just before
>the 
>line "do = do & oc"
>
>I would use this with "export word" which is csv.
>just: export word csv=(fn)
>no f=, r=\n etc..
>
>If the receiving app is choking on asterisks or semicolons, then write 
>an asterisk and a semicolon into a data field in that app, and export
>to 
>csv from that app, and see what the app wrote for that field. Whatever 
>it did, make gosub clean do the same thing, and the app should
>hopefully 
>import the same kind of data it itself exports.

-- Sent with K-@ Mail - the evolution of emailing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20140722/5ec12dbf/attachment.html