HELP! XMPie 6.0.2 Reversing Month & Day

[MailGuru]

We installed the XMPie upgrade 6.0.2 to our SI XMPie server. We did encounter the font restrictions problems like everyone else, and we worked around it by replacing fonts in all our documents (a large task since we are talking 75 or so different 24 to 36 page booklets).

Now, a week later, we found out that it has been corrupting our dates by reformating them to the European format. From a CSV file, we feed the data into the uProduce server as MM/DD/YYYY and it switches it to DD/MM/YYYY. This causes many problems with regard to expiration dates, etc. For instance, give it a date of "02/05/2013" and it will change it to "05/02/2013".

The problem has been escalated to tier 2 support, and, they say they have a resolution by using nested date functions within XMPie. We haven't tried it yet, but, I don't understand the logic behind XMPie changing the data we send it. When merging from a CSV text file, we would expect uProduce to place the field on the document EXACTLY as we have it formatted in the data. Is that too much to ask?

Has anyone else run in to this problem? How did you fix it?

 

[MailGuru]

The saga continues........nearing the end of the day, and, the issue has still not been practically resolved. Level 2 support has suggested the most outlandish work arounds I've ever heard of, and, none of them are practical. 1) "Use uPlan to specify that the date fields are numeric". Did that, now the month and day doesn't reverse, but, now we have to have a uPlan campaign for each of our documents. The uPlan will need to be update anytime we make a change to the document (which is quite frequent). Instead of 75 moving parts, I now have 150. 2) "Pad the beginning of the file with 15 to 20 blank records and use any numeric value in the date field of those 15 to 20 records so that XMPie gets the idea that this is a numeric field - which, it isn't - its "MM/DD/YYYY" - REALLY? R-E-A-L-L-Y? We are a high volume production shop. You telling me I've got to go in to each of the 300 files we run daily and pad with blank records?

Since most top-level support people tend to look at the most complicated solutions first, could it just be possible that the XMPie tech who upgraded our software via remote entry simply used a European version of the upgrade instead of the American version? I think the date format of DD/MM/YYYY is a European standard, right?


Hey, I looking for anyone who could shed some light on this. Anybody HELP!

 

[youston]

Had this issue pop up recently as well, but no uPlan here -- just using uDirect.

The issue arises because the field in the data is set as a 'date.' XMPie reads that and reverses the month/day. Pretty sure that we didn't install the European version of uDirect, too.

In one case, I can get around it easily because the date is the same in every record, so I just made that a static value that I manually update every time I run the job.

In another case, I have to apply a FormatDate function to the ador that puts the date value into the field.

Thanks for posting this ... I've been using XMPie for years and have never seen this happen until recently. I was starting to think I was going crazy.

 

[MailGuru]

Thanks youston. I really appreciate the response. I thought I was going crazy also.

We've already tried that. It only works if the day of the month is higher than 12. If the day of the month is 1-12, it still switches it to DD/MM/YYYY.

Last night, the problem was escalated to Tier 1. Hopefully, they can come up with a solution.

 

[youston]

I know you said you're high volume, but is it worth it to crack open the DB and reformat the field that has the date as a 'text' field?

Otherwise, we've found that pasting in a row of data that simply says "TEST" in every field will trick uDirect into thinking every field is a text field. Unless you're doing any calculating of values, you really don't need all that field formatting, do you?

Whatever happens, good luck, and please let me know what they come up with.

 

[MailGuru]

Thanks youston. We've already tried that, but, that work around is "file-count" related. That is, if you only send 50 to 100 records, that will work. If you send 2,000 records, XMPie determines it's field formatting based on a "ratio" of the field types in the record. For example, for a particular field, if 5 records are text, and the other 1,995 are dates, XMPie will decide that the field is a date and treat it as such.

Tier 1 is still working the problem. However, this morning we found a work around that actually works until XMPie can fix the problem: Parse the Year out as a separate field and then feed uDirect the date as two fields; Field 1 = "MM/DD" field 2 is "/YYYY". Then, in your uDirect document, treat as 2 separate ADORS that you place side-by-side.

While this requires a small programming change, it's easily done. However, it also means that all 75 different documents for this project will need to be modified and new C-Packages uploaded to the server, which, we are in the process of doing now.

 

[youston]

I considered parsing out the values and building a field out of the components early on, but ended up putting my foot down and saying, 'you know what? screw it. They're going to have to fix it.' Why should I have to jump through flaming hoops in order to get the value that's in the database into the document as is? I think they pushed out a European release as a US release ... hopefully, they'll realize that and sanity will be restored.

Please let me know what they come up with.

 

[MailGuru]

Update:

The problem was reported a week ago today.

No word from Tier 1 Support, although, we've been assured that they are still working the problem.......

"........all alone, at the end of the evening.........."

 

[MailGuru]

Ok, Tier 1 has solved the issue. Only took them 12 days. When we were given the server upgrade to uProduce 6.0.2, it also came with installer upgrades to uPlan, and uDirect. However, we were told that those don't need to be upgraded, just the server version of uProduce.

Turns out that they DO need to be upgraded. The new version of uProduce will treat a text field that looks like a date as a date, and reverse MM/DD. The old version of uDirect treats it as text and does not reformat the field.

With the new version of uDirect, using the "Format Date" function will translate to the uProduce server as a pre-formatted date and uProduce will print it exactly as it is received without reversing the MM/DD.

Even though it does fix the problem, it still doesn't explain the logic (or, lack there of) of why they want to mess with a text field in the first place. One would expect a text field to print exactly as it is, without changing anything.

 

[youston]

Well, I'm not using uProduce or uPlan. We're strictly a uDirect and then output from woefully-underpowered iMac shop. Same thing is happening, and without using 'format date.'

I think the next time it happens I'll log a service call and see what story I get.

I agree with you, though ... it doesn't make sense that they want to mess with the content of the data source.

Thanks for the info, though.

 

[PrePress Gal]

We haven't had any trouble in a long time. We added two lines of "fake data" or rather XXXX records to the beginning of each data field. Occasionally use a format date function.

 

[chaudoin]

I was able to resolve that same issue by making the date a variable vs. an ADOR.