Convert a Number field to Text/String field

[Alain Lina]

Hello everyone,

I know many people have asked this type of question before.

Is inserting a dummy line of data really the only way of making sure all your fields are viewed as text and not number?

We've only just upgraded from CS5.5 to CC2015 and this is a MAJOR headache.

I've tried workarounds, but nothing really works. We basically have to change our whole workflow.

I've tried to apply AsString to a number field but it doesn't work.

I don't understand why uCreate doesn't just let you choose whether to treat a field as number OR as text.
It would make things so much simpler.

We have to deal with Postal codes, ID numbers, Barcodes.
As far as we're concerned, there's never any arithmetic involved.

Having to insert a dummy line to fix the problem is forcing us to review EVERYTHING. Reports, workflows..

I know uPlan might be a solution, but we work with way too many databases to filter everything through that.

Help!

[couch]

Perhaps you could describe your workflow? I mean we could better provide advice if we know more about what you are doing.

General tips: 

* uCreate Print and uPlan set the data type only for csv/txt/excel because those file types don't define data types. - IE if data type it is critical, use SQL, Access, etc which use strongly typed data.

* uCreate Print and uPlan set the data type when you link to the txt/csv/excel files. They look at every field in the column before setting a type. IE if it finds one cell with text or padded numbers, in a column that otherwise has only numbers, then it will set that column to text data type. - Therefore, I suspect that your workflow is using some temporary data file and then changing to another data file which has different types of information in the same column? 

* As you suggest, when you use uPlan you can change the data type of the field in the recipient schema if you know that the data source will change and will have a different data type in future.

PS: having a dummy row should not affect your reports. options:

1) after linking to your "dummy data file" - you can relink your document to a different data file. - the adors and recipient schema are already created.

2) even if you add a "dummy line" as the first row - your production should be from record 2-n - that way, all your reporting is showing only those valid records which you printed.

[Alain Lina]

We mostly work on mailings.

We've got database technicians who work on our customer's databases.

They use Foxpro for most of the programming. They also use a bunch of other programs depending on what they have to do (Flagship for Canada Post..).

So all the data reports are exported from that.

When they're done, they send us "formatted" data, for either laser printing or inkjet.

That's where I come in with XMPie (prepress).

We work on Mac, so our database techs send us 3 types of data: CSV, Mac formatted CSV (for french accents) and XLS for reference.

Obviously we use the Mac CSV when working from the desktop application (uCreate) and the regular CSV when using uProduce.

We don't always use uProduce because it involves converting fonts to PC compatible - which is sometimes not worth the effort, depending on quantity.

In any case, we use uCreate to program rules for VDP.

Using a dummy line works, and we've managed to fix our reports (Foxpro) so that it doesn't show up.

But it's still a pain having to do it. Guess we'll get used to printing 2 to N..

Still, I would be so much simpler if uCreate would let you choose how interpret the field instead of choosing for you.

Thanks for your help!

--
You received this message because you are subscribed to the Google Groups "XMPie Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xmpie-users+unsubscribe@googlegroups.com.
To post to this group, send email to xmpie...@googlegroups.com.
Visit this group at https://groups.google.com/group/xmpie-users.
For more options, visit https://groups.google.com/d/optout.