What is the calculation? Have you checked it since the database was converted to make sure the conversion process didn't affect it somehow?
If I run it from the client, it works perfectly. ITs just on the server it does not work which I find wierd.
The calcs are
xc_dripWeeks<--If not in a group then 0 otherwise give me xc_NoofWeeks
xc_dripGroup <--- this is a case statement which checks to see if a calc is in a specific stage it should be in a specific group (Ex. xc_stage=19;"Group A";)
Not sure that helps me diagnose your problem much. What determines if a record is in a "group"? Do you mean an Active Directory group?
Have you checked to make sure the account used on the server has privileges to see these calculations?
What about context? Does the script account have access to see the layout?
The stage in their in determines what group they are in. The stage is from a related table. All permissions and priveledges are set correctly. Im so stumped on this because I did not have this problem in FM 11 Server when I would run it
Is the related table in the same file? If not, is that file in the same directory on the server?
All the same file. I know this is just wierd isnt it lol?
Hm. Let's back up. You said the find doesn't seem to process correctly. What about it isn't right? Is it finding all records / no records / incorrect records?
When I perform the find on the client side it produces the right results. When I perform the find from the server it returns much more records. The result is incorrect.
Are you getting any errors in the server log?
what about the find context? Is it possible that the server is on the wrong layout?
No not possoble its the same script on client and same script on server
Sent from my iPhone
This criteria was a calculation. FM11 would always give me the correct find results but FM12 does not seem to find correctly.
The fact that it worked in 11 and the exact same thing breaks in 12 points strongly to a behavior change. It is possible, particularly if your calculation involves the current date, that in 12 your calculation is being evaluated by the server instead of the client (see link) or that an unstored calculation is not evaluating (see quoted text below).
Unstored calculation field evaluationchanged
Some customer solutions assume that an unstored calculation field will be evaluated when a layout containing the field loads, even when that field is completely hidden by other layout objects.
I truly wish you well in pinning it down; these things can be difficult to pinpoint.
Also, can you confirm that you have the latest FM Updater for your platform? Thank you!
Message was edited by: LaRetta