Deleting Grid Formats

Hi List,

When we go to SP17.1 from previous SP15.1, we removed the entries in the F98950 table, because the BLOB format has changed to xml.

I create a new grid format. OK. When I go to P98950, find that GF line, hit Delete, this takes a while to do this suppression.

When I looked to jdedebug.log, I saw that JDE tried to delete the GF from UOSEQ=0 to UOSEQ=18020, so 18021 SQL requests are done and that's why suppress is too long.

When I looked to the B9800950, the system read from record having UOSEQ=0, then, get from the BLOB the number of formats (nNumFormats variable), and loops from 1 to nNumFormat (which is equal to 18020) and execute the Delete for that UOSEQ.

Sure that the storing of nNumFormat in the BLOB is bad or something is going wrong.

Has anyone encounter that problem and what is the solution ?

Other thing: on some machines, in any form having a grid, all users can create new formats (tabs), but some cannot remove nor rename the format. Has anyone got that kind of behaviour ?

Maher SAMET

Config: B733.2/SP17.1 on NT4.0/SP6a and SQL7/SP3.

Hi Maher

I have just caught up with my JDEList reading and am disappointed that nobody has responded to your post. We have the exact same problem as you describe in relation to deleting Grid Formats - it takes approximately 7-10 minutes at our site. We have recently upgraded from SP11.1 to SP17.1_H1.

I have logged a call with JDE, but no solution has been provided as yet. Initially, they thought it was something to do with Client Access (for the AS/400), but we have also just upgraded the AS/400 to the latest available.

I will keep you posted if JDE come up with anything. Please let me know if you discover anything.

Until you find a solution, just remember to keep smiling !

By the way - my users have not reported the problem of being unable to rename/remove grid formats.

Ian

Maher

The following is an extract from our JDE consultant who is working on this issue
for us.

"Development has decided to submit a sar for the user override issue. Let me
know if you have any questions, thanks. It is sar 6133891 and the text of
the sar request is:
B9800950 needs to change the way it fetches GD record. It needs to fetch
the GD records based on USER, OBNM, FMNM, UOTY, LNGP, and VERS until the
fetch fails. Do not cast the GF record to LPGRIDFORMAT since the BLOB is
no longer a binary blob."

I have noticed that the SAR mentioned is not on the knowledge garden yet - maybe
tomorrow will see it there...and then we will be awaiting the fix for it.

Ian





maher_samet <[email protected]> on 18/04/2002 07:21:20 PM



B733.2 SP17.1_H1, A73 Cum 11 (Payroll)
Ent AS/400 V5R1, Dep NT4 SP5

It seems to me we had this issue back on B733.1 and we resolved the issue by adding a new index to the Oracle table (probably F98950) after analyzing the SQL statement being issued. I don't know if this is your problem, too, but it might be worth a look.