E9.2 UBE gives different outputs between local and web server

Rana22_

Member
Hi,

I created a custom UBE that was supposed to print out a 'before' and 'after' values of a table.
How it is designed is I am printing the current values of the table in a section, call another section that does the table I/O update, then call the last section that would perform a Fetch on the new values and print it at the bottom of the report.

Testing and running the UBE locally works perfectly, but when we deployed it to DV the 'before' and 'after' values shows up the same (all the values being printed are the post upload data). It seems like the 'before' values that were supposed to be already printed gets overwritten.

Any idea what could be happening?

Thanks.
 
First the obvious. Are you sure the UBE was actually deployed? I would try another build/deploy first

Tom
 
First the obvious. Are you sure the UBE was actually deployed? I would try another build/deploy first

Tom
Hi Tom,

Yes. The OMW project containing the UBE has been deployed to DV twice now, both giving me the same results. Prior to the second deploy I made some formatting changes to the UBE too, and I was able to see those changes after the deployment. I'm wondering if there are any differences with how the table I/O functions between local and web server?
 
I'm wondering if there are any differences with how the table I/O functions between local and web server?
To begin with: there shouldn't be!

Did you deploy the report via update or full package? Sounds like some corrupt specs to me. Depending on your OS you could also see if there's anything in RuntimeCache for the UBE on the enterprise server.

When you say before/after are the same - are they the same in the table as well? Did the update on the table run?
 
Years ago, I had the same problem. I finally tracked it down to the ODBC connection on my local workstation. In my case, the UBE selection statement (that happens after the Initialize section) was generating a large result set. As a result, the result set was being restricted by my the local Windows ODBC connection driver. My case would be that the SQL statement was timing out -- under the hood. The ODBC connection, in my case a Windows ERP logic server, did not throttle the result set. I had this problem at release level 8.0 (E1) a long time ago. It fixed it, I forced the user to make smaller data selections by adding additional data selection in the version.
 
To begin with: there shouldn't be!

Did you deploy the report via update or full package? Sounds like some corrupt specs to me. Depending on your OS you could also see if there's anything in RuntimeCache for the UBE on the enterprise server.

When you say before/after are the same - are they the same in the table as well? Did the update on the table run?
Hi Schojo,

It was through an update package.
The update on the table run properly, it was just the printing of the values before the update that has an issue. The UBE was supposed to print out what originally is in the table, then call the table update, and then later select the new values of the table to print it (these steps are all in different Sections). This logic works in local server, and I even followed the flow of data through debugger. However when I run the same UBE in DV, everything that gets printed is just the new values of the table, even on the fields that supposed to have printed the data before update.

I'll try to check if I find anything about the RunTimeCache you have mentioned. Thanks!
 
other things i'd also try:
- Full Package, just because.
- debug the report on the server vs. locally, see differences
 
Finally figured out and resolved this issue, just in case anyone runs into the same error:
It has something to do with the business view I am using in the report.
The view joins two tables that have the same prefix, and basically what happens in the server is that if the tables have the same data item, the data item's values from the primary table gets inherited to the other table, which is what's being displayed in the report.

Solutions are to change the prefix on one of the tables (if it is a custom one), or manually reassign values to the second table of the view through FetchSingle.
 
Back
Top