Question Missing field using data dictionary dump and load

[Chris Hughes]

Hi

I have a table which has 7 fields.

Dumping it from an older db structure dumps 7 fields per row.

I import into new db structure and for some reason in only tries to import 6 fields - although 7 are definitely there.

I wrote a little bit of code

For each table:
update table.

Only 6 fields are shown.


I don't see anything obvious in the dictionary that says to ignore the 7th field I want.

Any ideas?

10.2B sP7

Cheers

 

[Cringer]

Go to the table in Data Administration and dump a df for just that table and post it here if you don't mind?

 

[Chris Hughes]

Hi Cringer

Don't think I can do that - get my hands slapped an all that

I did what you said though and I think I understand a little more - the field in question is of a "recid" type - is this why?

Cheers

 

[Cringer]

Why have you got a RECID in your schema? That's a pretty big no-no. There's no actual guarantee that the RECID will be correct. There's more info here: https://community.progress.com/technicalusers/f/18/t/10429.aspx?pi624=1#41595

 

[TheMadDBA]

Yes... Progress will not display/update a RECID field by default. You can code around it, but for the love of Pete don't store RECIDs in the database if you ever care about your data

 

[Rob Fitzpatrick]

Since a recid is the physical address of a record within a storage area (I'm omitting the cases of multi-tenant tables and table partitioning for the sake of simplicity), stored RECIDs are pretty much guaranteed to be wrong once you dump and load them (and possibly even before that, e.g. due to a proutil tablemove). And as the others have said, just don't store them at all.

 

[Chris Hughes]

eek - understood.

How do I code round it - import and manually set all 7 fields at a guess?

Its a dozen records on a little used table - just my strive for perfection to get a 100% record count match on a dump n load.

 

[Cringer]

If you're doing a dump and load then the recids will be wrong anyway, so why bother?

 

[Rob Fitzpatrick]

Also, I don't understand the logic of someone who would allow you unfettered access to a procedure editor and to dump and load data, but would "slap your hands" for dumping a schema file. What do they think a schema is?

 

[Rob Fitzpatrick]

How do I code round it - import and manually set all 7 fields at a guess?

Its a dozen records on a little used table - just my strive for perfection to get a 100% record count match on a dump n load.

Once the records are stored you can find their recids with the RECID function if you really feel compelled to store it. But if the table is truly "little-used", does it matter?

I'd be inclined to find the offending programs that use the recids and fix them, rather than perpetuating a bad design.

 

[Chris Hughes]

I guess that's the danger of posting to the development area - not in my power to fix the code.

I am a mere installer / configurator

Does it matter - probably not - just like to know why (been like that since I was 5 years old)

 

[TheMadDBA]

Best to look at the code referencing these tables and the others. Doing a dump and load with code that stores RECID/ROWID is usually a recipe for disaster.

Trust me... they will blame you when it all goes wrong

 

[Cringer]

Also, I don't understand the logic of someone who would allow you unfettered access to a procedure editor and to dump and load data, but would "slap your hands" for dumping a schema file. What do they think a schema is?

As I understand it he can access the schema, he'd just get his hands slapped for providing that info in a public forum.

 

[Rob Fitzpatrick]

OK, fair enough. I missed the "and post it here" the first time I read it.

 

[RealHeavyDude]

Believe it or not, there are people ( which would inlcude myself ) that would risk their jobs by posting any kind of source code that could be intelectual property of thier employers in any way ( even if it is derived from open source ).

Heavy Regards, RealHeavyDude.

 

[Cringer]

My contract has that clause in it. In fact I think I could technically be fired for writing code on here in answer to queries if I do it on company time...

 

[Rob Fitzpatrick]

My contract has that clause in it. In fact I think I could technically be fired for writing code on here in answer to queries if I do it on company time...

It's our little secret. You, me, and the Google spider.

 

[TomBascom]

If you insist on storing data that contains RECIDs in a database field then you must have a method of reconstructing the RECID from some other key.

Maybe someone decided to do that "for performance reasons" (lookups by recid don't read index entries...).

For instance, perhaps your order details records store the order header recid *and* the order header number. In a case like that you can always rebuild the RECID with code something like this:

for each orderDetail:
  find orderHeader where orderHedaer.orderNum = orderDetail.orderNum.
  orderDetail.hdrRECID = recid( orderHeader ).
end.

If you have RECID fields but no way of reconstructing the correct RECID you are doomed.