Headerless Detail not updating - WHERE shows blank key col

[Frosty the Coder]

List,

I have a custom table KCOO, DOCO, DCTO, EUSE, DSC1.
KCOO, DOCO, DCTO, and EUSE are keys.

I have a headerless detail, where KCOO, DOCO and DCTO are filters. (I want this table maintained at the ORDER level.)

Adds work fine.

Updates fail.

JDEDEBUG.log shows the UDPDATE statement with the SET being correct for all five cols,
but the WHERE showing EUSE as blank.

I tried assigning BC EUSE = GC EUSE in the "before update" event, but that didn't work.

What's the solution?

TIA

Gene

 

[Pon]

Hi Gene,

I'm having a similar problem. I have a custom table with two keys (say key1 and key2). I have key1 as a filter and key2 on the grid (along with all the other fields from the custom file). I'm able to add and update just fine to all of the fields but key2. I'm not getting any errors it just never puts anything but blanks in the key2 field. I think we're missing something about how key fields work on a headerless detail. Have you found anything out concerning this problem?

Thanks.

 

[Frosty the Coder]

When doing an ADD, I always do an assignnment, in BEFORE GRID ROW IS ADDED, where I set the BC (keys) to the GC (keys).

I _think_ if a control is used as a filter that it doesn't get passed to the BC. This doesn't alwasy seem to hold true, so I've taken to always assigning the key(s) during an add.

Gene

 

[Pon]

Thanks for the info. I wouldn't think that this method would be standard protocol for a headerless detail though. Maybe someone else can chime in and explain this phenomenon.

Thanks.

P.S. I forgot to mention, your suggestion did solve my problem. I set BC Key2 = GC Key2 on Update to DB before & Add to DB before events.

 

[Adrian_Chimirel]

I've had the same issue you had when one of the Form's Options was NOT Standard (and I did not find out how that option got un-checked!). See Attachment.
The idea is you do NOT Update your table through form's business view (BUT through Grid's business view), otherwise you could get, sometimes a "Duplicate not allowed" error, OR, and that is your case, OW just blanks out your field

 

[Larry_Jones]

Hi Gene,

have the current table specs been deployed to the ES?

I have seen the type of behavior you describe when the ES didn't have the table specs.

Regards,

 

[Ben_Britain]

Flying blind here but if it is similar to my problems in the past then you have asterisks in your filter fields above the grid. Try filling them in with the actual values you want updated. Then try filling in just one or two and watch the SQL statement. Let us know.

Ben again

 

[Frosty the Coder]

Thanks, all, for the replies.

When I described the issue to help desk, she described to me, in detail, exactly how I'd gotten into this mess.

I had a table, bsvw.
I created, and tested the appl.
I realized my key was incomplete for my needs.
I did the remove table from db, mod'd my key, regen'd, checked in.....
I tested and found that I'm having problems.

She also pointed out that this cust is on a 400, which requires that I delete the SQL package.
THIS requires that I plead w/a CNCer to (again) bail me out.

Anyway, that's where we are.
I'm waiting for CNC to delete the SQL package, and we will see what happens.

Thanks again for the replies.
I'll post the followup when that occurs.

Gene

 

[Frosty the Coder]

Res: Headerless Detail not updating - WHERE shows blank key col

After some debate, it was decided that I could try to delete the SQLPKG.
Rather than delete many that I wasn't sure of, I stumbled onto 1 (in 3 libs) that had _my_ userid,
and was created at the same time that I had changed the key.

I deleted this from all 3 libs, but the appl still refused to update.
I tried creating a new appl, over the old bsvw, but that didn't work either.
I ended up creating a NEW (diff name) table, bsvw, appl, ube,...

Anyway, the ugly workaround did the trick.

Thanks to all.

Gene

(new thread to follow)

 

[danielpcl]

Hi all.

After 22 years, I faced the same issue from this topic.

In my case, just opening the BSVW, and saving it again, solved the issue. Everything worked fine after this.

(Also, it took me a few hours to find this issue, and I have no idea why this happened.)