Solved

Custom Logical Unit: Order of fields in generated table?

  • 28 July 2021
  • 5 replies
  • 241 views
S
Rank
Userlevel 6
Badge +12

Hey all,

I am developing a custom routine (in C#/.NET) to generate Custom Logical Units (CLUs) and all the custom field attributes to go along with them. My goal is to be able to point to a DBF file (Foxpro data) and create a CLU that matches the structure of the DBF column for column. And it works!

Except for one thing. Though I add the custom fields to the CLU in the order the columns are found in the DBF (from left to right, by ordinal position), when the CLU is published and the _CLT is created, the fields are in alphabetical order. It is not a big deal, but it would be nice to be able to compare the resulting CLT column by column to the original DBF and verify that data types and sizes look good. This is easier to do if columns are in the same ordinal position.

Any way to control the order of the table columns? When I look at custom attributes we have added to existing LUs I see those fields are in alpha order as well, unless a field is added later on -- then it is attached to the end of the structure. I am assuming that if a CLU is published, that commits the structure, and fields added afterward are added in order? That means I could add fields one at a time and Approve/Publish between each field addition, but that sounds time consuming and database-intensive (I have it automated, but still). I’d rather control the ordinality of the columns as I add them all at once.

Anyone know how to do that? Is it possible?

 

Thanks,

Joe Kaufman

icon

Best answer by sutekh137 28 July 2021, 23:53

View original
Just because something is part of a plan doesn't make it right.
This topic has been closed for comments

5 replies

S
Rank
Userlevel 6
Badge +12

Quick addition: Yes, I can preserve field order by Publishing between each new custom field being added. Though, even then the structure is somewhat goofy, because the first three fields are:

ROWKEY, <first field added>, ROWVERSION

and then rest of the fields list in order.

And it is slow. For a 15-column conversion, the process takes 50 seconds when publishing after each field. Publishing just at the end makes the process take only 3 seconds.

Finally, pulling data from the View instead of the Table still results in the fields being listed alphabetically, so preserving ordinality in the _CLT is not of much use.

It would be nice if the column order could be controlled as well as honored by the _CLV.

 

Thanks,

Joe Kaufman

 

Just because something is part of a plan doesn't make it right.
durette
Rank
Userlevel 7
Badge +18

If you only need a column comparison to make sure the metadata matches, try querying USER_TAB_COLS while logged in as the app owner.

If you find this forum useful, please consider paying back to the community in your own areas of expertise. -- Kevin Durette - https://www.linkedin.com/in/kevindurette
S
Rank
Userlevel 6
Badge +12

If you only need a column comparison to make sure the metadata matches, try querying USER_TAB_COLS while logged in as the app owner.

 

Thanks, Kevin, a fine idea. I always need to remind myself of all the meta-data housed in Oracle (and most server-based DBMSes!

 

Thanks,

Joe Kaufman

Just because something is part of a plan doesn't make it right.
durette
Rank
Userlevel 7
Badge +18

 

I always need to remind myself of all the meta-data housed in Oracle

There’s a lot to remember, so every developer and admin should keep this one handy:

SELECT * FROM dictionary;

 

If you find this forum useful, please consider paying back to the community in your own areas of expertise. -- Kevin Durette - https://www.linkedin.com/in/kevindurette
S
Rank
Userlevel 6
Badge +12

 

I always need to remind myself of all the meta-data housed in Oracle

There’s a lot to remember, so every developer and admin should keep this one handy:

SELECT * FROM dictionary;

 

 

Bertrand Russell would be proud! Is dictionary in the dictionary?  *smile*

 

JoeK

Just because something is part of a plan doesn't make it right.
Terms & ConditionsCookie settings