EO810 # in data item

[Gergely_Pongracz]

Hi List,
I have a strange issue here and I am wondering if anybody has seen anything like this before...
In EnterpriseOne 8.10 I tried to write a batch that inserts data into F0911Z1 and my RDA froze with a Memory Violation error each time I chose this table for Table I/O.
After a little searching I found that Table I/O worked correctly with most tables but froze for all tables where one of the data items contained a '#' character e.g. F0101Z1, F03B11Z1 etc. By the way I found it very interesting that a DD alias should have a # in its name...
I made a quick check and it seemed to work on EO8.9.
Has anybody seen anything like this???
Regards:
Gergely Pongrácz, e-Best, Hungary
Current System is EO810 on Windows/DB2

 

[Robert Robinson]

We are proofing our installation of 8.10 in the PY environment. To date, we have run into several instances where we receive the following message:
"Business Function has caused a memory violation. [Invalid Overwrite or Read]
There has been an error running the following Business Function:"
Function name is here
"This is commonly caused by errors in the logic of the business function or a business function that it calls. It can also be caused by changing a data dictionary item without regenerating tables or recompiling business functions that use data dictionary item."

The functions that we have seen in error so far are:
GetDistributionConstants
DetermineEnabledProcesses
GetTagFile
F4311SBeginDoc

Have not yet located the DD item(s) causing the problem. We are not seeing this type problem in our 8.10 Pristine Environment. It is interesting to note that we had DD problems when we migrated from World to Xe (we had old leftover 5.1 DD items that were not cleared out which then caused problems when we started to use Xe).

 

[Robert Robinson]

A follow up...

the memory violations that I mentioned earlier were all linked to a corrupt DD item CP07...once we recompiled this item, then removed the "big 6" tables (dddict,ddtext and the global tables) and allowed the system to JITI new spec items, the memory violations ceased to occur.