Hello,

We had a strange problem whereby in psm 7 we had a variable linked to a data field (Trim([number])) being replaced by the 1st record value and all subsequent records had the 1st record data value.

I cant see how we would of manually typed in the 1st record value over the variable.

Does anyone have any idea if psm is capable of this type of error?

Its expression changed? That's not a known issue. It would be great if we could find out what triggered that to happen.

Same thing happened to me a while ago, I thought I was going crazy.

Cant remember what changed that could have triggered it though.

Hello

Its expression changed? NO IT DOES NOT CHANGE IT DISAPEARS AND IS REPLACED BY THE VALUE OF WHAT EVER RECORD IT IS ON SOME BECOMES TEXT

I have had this again today not sure what the cause is but it seems to be releated to objects becuase I had a object with 10 expresions in and on mass they all changed to the first record of the file copied the same fields back into the same object (from word) and it did it again, created a new object and copied in the expressions and it was fine.

Have had it twice in one file today and it has caused 1 job to go wrong so this is serious for me, will log a call with support tommorrow and try and save a file when it happens.

We also had this exact thing happen to us. We have been using PSM7 for a while and did not have this problem until recently. We had to rerun a job for 21,000 duplexed sheets because of this problem. When we went to rerun the job it did exactly the same thing at a different part of the data file.
We did not save the file when it happened and when we went to open it again the merge field was there and not the static info.
We do not have an expression in the field. We are reading directly off the data file.There are 10 merge fields in on the front and 10 on the back of the sheet and only one field converted to a static of one of the records.

We're postponing the release of the next update for 7.0 in order to get this fixed, but we'll need more info.

It would be a great help if we could see the document file (psmd) in its original state. There is no need for any other files, the psmd file is sufficient.

One particular point of interest is whether you're using OBJECT_EMPTY, and if you are, exactly how.

In terms of what we wre using we were not using and functions just the [field] itself.

I have noticed you have released a new version does this attempt to correct this fault ?

Yes, it includes an attempt at a fix. We've seen this problem occur when an expression in a text object uses OBJECT_EMPTY (directly or indirectly) to refer back to the same object, or to refer back to another object in the same chain of linked objects. Reentrancy causes a problem in the registration of variables.

If you're not using OBJECT_EMPTY in any expression (anywhere, not necessarily in the object that exhibits the problem), it may be possible that something else is causing reentrancy. In that case the problem is still likely to be fixed in 7.0.2. I can't confirm it yet, I'll examine your *.psmd files and see if I can detect a pattern.

Thanks,

Sander

I think we found the cause.

It looks like the Excel driver can cause reentrancy (through the COM message loop), particularly when the database is open in Excel while you're working with PSM. So far I haven't been able to reproduce it with any other type of database.

Since we are guarding against any form of reentrancy in 7.0.2, I'm confident that it is now fixed. Please let us know if you still experience this problem after upgrading to 7.0.2.