Importing concatenated fields

[The Mad Jammer]

I am moving data from a Clarion database application that I wrote years ago to an FMP 6.0 database. The Clarion utilities afford me the opportunity to convert the database files into ASCII comma delimited files. I will write a VB conversion routine to split the file into several files and normalize the data. I wish to combine the address, City, State and Zip Code fields into one field on FMP 6.0 when I import the ASCII file. How can I accomplish this task? I suppose I will need to import each field separately and use a calc field to concatenate them but that is such a waste of space. What I would like to do is concatenate the fields in the VB program and insert the vbCR & vbLF characters after the address. Does FMP understand what a CRLF is when it is importing the field? Or do I need to insert the reverse P character after the address? BTW, how do you insert that character in FMP anywya? I've seen it in some sample scripts but don't know how it got there.

Thanks

The Mad Jammer

And then...there was nothing

[LiveOak]

First, I probably would keep the city, state and zip separate. You can always combine them, it's harder to split them up when you want to do a zip code sort. I think you're gettin manic about the "waste of space". I would import the three fields and the create a calculation (unstored) field to combine them for use. This really doesn't add any size to the FM file.

I think you are just comfortable with VB and still a little uncertain in FM.

-bd

[cjaeger]

i would rather import every line of the comma-seprated fiel into one field "import") , import as tab-text and use auto-enter calcs to split into individual fields. no vbs needed

field 2= Middle(import,position(import,";",1,1)+1 ,position(import,";",1,2)-position(import,";",1,1)

field address_zip= Replace(Middle(import,position(import,";",1,3)+1,position(import,";",1,6)-position(import,";",1,3),";","q|")

(q| - stands for return char)

[The Mad Jammer]

Perhaps importing all the fields separately and then using a calculation field to display them is the way to go. On the other hand, the only time the calculated field would be of any use is in a report or something of that nature, when zip sorts or city finds are not going ot be invoked. I simply would like to see a text box with the name, address, city state zip all in one area, but alas...

Thanks for your input.

The Mad Jammer

And Then...there was nothing