E9.2 Application & Table Modification

Jeff George

Jeff George

Well Known Member
I'm working on a modification update that requires adding an additional field to the form header. I've already added the new data item to the table, business view, etc. However, when I try to test the application on local Web, I get the following error message when trying to save the data:

1680197187019.png
DRY57QCBNM is the SQL name of the field I added to the table. I thought that this meant that the application couldn't see the new field in the table, but our managed services CNC people said that adding a new field to a table shouldn't be an issue. Did I mess a step that I have to execute before this table change will work?
 
Maybe i misread it, but was the table generated so the new column is included in the actual table on the database or did you just add it to the object?
 
The table was not generated, though I was under the impression it would have to be.

Here is what the managed services CNC wrote to me when I told them I needed to generate this table. I thought I had to generate the table on my fat client to make the new column available. I thought this would automatically update the database to include the new table. It looks to me like they are saying otherwise.

'Adding a column in Oracle does not wipe out any of the existing data or cause the table to become unavailable to any applications using the table. All of the existing rows receive a null value for the new column or the default value if the default has been set during the column addition. Altering the table to add a new column is the best method to handle a column addition.'
 
Also try clearing the 6 seup files on your FAT client, DDDICT DDTEXT etc.
If you generated the table then it should be fine. Try doing databrowser from inside your APPL to see if the new column is there,.

But it could be you haven't generated the table....?
 
The table was not generated, though I was under the impression it would have to be.

Here is what the managed services CNC wrote to me when I told them I needed to generate this table. I thought I had to generate the table on my fat client to make the new column available. I thought this would automatically update the database to include the new table. It looks to me like they are saying otherwise.

'Adding a column in Oracle does not wipe out any of the existing data or cause the table to become unavailable to any applications using the table. All of the existing rows receive a null value for the new column or the default value if the default has been set during the column addition. Altering the table to add a new column is the best method to handle a column addition.'

You have to generate the table on the database to get that extra column.

Sounds to me like that they are saying they will add the column via an ALTER statement using SQL rather than you using TDA to gen the table
 
You have to generate the table on the database to get that extra column.

Sounds to me like that they are saying they will add the column via an ALTER statement using SQL rather than you using TDA to gen the table

That's kind of the feel I'm getting, but I'm not in favor of that idea. This table is in an OMW project that I'm working on. Just let me generate it and move on.
 
FYI, I can see the new column on my fat client in UTB. This is the sort of thing that annoys me about managed services. If I don't need you to do something for me, don't make me wait and hold up my progress. This ain't my first rodeo.
 
If you generate the table from TDA, you will wipe out any existing data in that table. BEWARE!!!
Altering the table and adding the field can work, though you need to be very precise on how you define the new field. Or you could copy off all the existing records to a temporary table, regenerate the table, and then copy the temporary table records back into the newly-regenerated table.
 
If you generate the table from TDA, you will wipe out any existing data in that table. BEWARE!!!
Altering the table and adding the field can work, though you need to be very precise on how you define the new field. Or you could copy off all the existing records to a temporary table, regenerate the table, and then copy the temporary table records back into the newly-regenerated table.

I understand that, but that's not a significant worry. If I decided I did want to repopulate the table, could I do a table copy from PY to DV in TDA, even though the DV table has one additional column?
 
I understand that, but that's not a significant worry. If I decided I did want to repopulate the table, could I do a table copy from PY to DV in TDA, even though the DV table has one additional column?

Edit: Sorry i misread that, you're trying to use TDA for that. Pretty sure you can't do that there and the report for copying data from one ENV to the other will most likely fail because of the column mismatch ...

Absolutely, you just have to make sure that what's in your SELECT matches the destination, by simply adding the new column and value to your statement:

Old.Table: a.column, b.column
New.Table: a.column, b.column, c.column

SQL:
INSERT INTO New.Table
SELECT a.column, b.column, 0 FROM Old.Table; -- or ' ', 'TEST' or whatever
 
That's kind of the feel I'm getting, but I'm not in favor of that idea. This table is in an OMW project that I'm working on. Just let me generate it and move on.
Create a quick headerless detail over your table (without your extra column just yet)

export ALL data to excel

build your table with your new column added

Add your new column to the view and screen

go back into your headerless detail screen

import the data back in

Job done

(take that APPL with you all the way up to PD)
 
Create a quick headerless detail over your table (without your extra column just yet)

export ALL data to excel

build your table with your new column added

Add your new column to the view and screen

go back into your headerless detail screen

import the data back in

Job done

(take that APPL with you all the way up to PD)
I guess that really depends on how big the table is 😅
 
I hate table conversions as much as the next developer, but isn't this what they were intended to do?
 
If all else fails and the added column isn't recognized by your interactive app, bounce the web server(s). Dealt with something like this recently. Databrowser would recognize and return data but a table IO wasn't finding the new column and the log even said their was a spec mismatch.

Note on table conversion since it was brought up...been doing heavy JDE dev work for 23 years. I never ever use table conversions - they suck - I instead code a regular UBE using the flat file and parse delimited string functions. Way more more flexible in terms of input, output, logic etc.
 
If all else fails and the added column isn't recognized by your interactive app, bounce the web server(s). Dealt with something like this recently. Databrowser would recognize and return data but a table IO wasn't finding the new column and the log even said their was a spec mismatch.

Note on table conversion since it was brought up...been doing heavy JDE dev work for 23 years. I never ever use table conversions - they suck - I instead code a regular UBE using the flat file and parse delimited string functions. Way more more flexible in terms of input, output, logic etc.
I agree on the "Table Conversions = Very Inefficient to code" but rather than code a UBE (almost as inefficient to develop) nothing beats SQL for a quick and dirty solution.
 
I finally succumbed and let CNC do it their way. Luckily, it only took about an hour to get it taken care of. Still too long in my mind for getting a single new field into a couple of tables....
 
如果所有其他方法都失败并且您的交互式应用程序无法识别添加的列,请退回 Web 服务器。最近在处理这样的事情。Databrowser 会识别并返回数据,但表 IO 没有找到新列,日志甚至说它们是规范不匹配。

关于表转换的注意事项,因为它被提出来......已经做了 23 年的繁重的 JDE 开发工作。我从不使用表转换——它们很糟糕——我改为使用平面文件编写常规 UBE 并解析分隔字符串函数。在输入、输出、逻辑等方面更加灵活。
hello,i want to set datebase output in UBE,but i can't operate it,could you give me some tips
 

Attachments

  • 图1.png
    图1.png
    37 KB · Views: 9
Back
Top