create incremental .df file produces updates for char fields that want set decimals 0

[StoneKeeper]

hi there,
here, i have two production db's. They should have same structure (both are progress 10.1C). After a differential i got a lot of this:

e.g.

UPDATE FIELD "email" OF adresse
DECIMALS 0

.. for many character fields.

After researching i found, that in _field table somethimes decimals for char fields is 0 and somethimes it is ?

So i tried to create a complete new character field in the data dictionary -> the decimal value is ? - so i guess this is right.

Loading the above mentioned definitions is not possible because of following message:

**MODIFY FIELD xxx caused a warning **
Can't change Decimals of field "xxx". Field type is not DECIMAL.


Question now is: can i update table _fields where decimals = 0 and set this to ?
Must we recompile all source codes after this update?
Is there another way to fix this - i know, update the internal tables is never a good idea!


ps: I could imagine, that this bad situation is a result from converting progress db's 8 to 9 and then 10!

regards
Horst

 

[cj_brandt]

Re: create incremental .df file produces updates for char fields that want set decima

How large are the tables ? Is renaming the existing tables, creating new tables and then moving the data over an option ?

 

[StoneKeeper]

Re: create incremental .df file produces updates for char fields that want set decima

Thank you for this suggestion, but this is not possible.

In the meantime i tried to code a small progress script, that based on tables _file and _field creates a incremental .df file with update decimals statements. It should be possible to load this via data administration to set all character fieds with decimal 0 to ?.

As i have seen, even some progress internal system tables have a 0 instead of a ? in decimals attribute for fields.

e.g.

table, field, decimals
_SQL_Properties _Value_ch 0
_Sysattachtbls _Dblink 0
_Sysattachtbls _Linkowner 0
_Sysattachtbls _Owner 0
_Sysattachtbls _Remowner 0
_Sysattachtbls _Remtbl 0

 

[TomBascom]

Re: create incremental .df file produces updates for char fields that want set decima

If it really matters (I don't see that it does, but maybe I'm missing something) you could do a clean dump & load. Prior to loading the .df file scrub the decimals values from character fields.

 

[StoneKeeper]

Re: create incremental .df file produces updates for char fields that want set decima

Thank you for this tip. That works of course, but is very time consuming - we have to maintain about 10 production db's. Therefore, i am looking for a faster solution.

And yes, it matters because every incremental .df file includes many of this

UPDATE FIELD "email" OF adresse
DECIMALS 0

commands.

A load of such a df file to upgrade all db's to newest data structure produces a lot of warnings - and i do not like this warnings during db structure updates. Also checking .df upgrade files is more complicated, because of this decimal updates ;-)

 

[TomBascom]

Re: create incremental .df file produces updates for char fields that want set decima

I think that your first problem is that you generating an incremental .df between production databases.

Why?

Are you doing development in production?

 

[StoneKeeper]

Re: create incremental .df file produces updates for char fields that want set decima

You are right. Currently we have - a master production db. After definition of data structure we generate db changes in this master db.
Between this db and all other production db's we generate .df files. Thereafter we code, test and rollout the sources.

And yes, for small projects or urgent and needful changes, we do developement in production!

 

[TomBascom]

Re: create incremental .df file produces updates for char fields that want set decima

You're doomed.

 

[TomBascom]

Re: create incremental .df file produces updates for char fields that want set decima

Stop doing that before you shoot yourself in the foot while holding said foot to your ear. Sit down and get your change management process under control before it is too late.

For this particular problem: Create a development database. It can be a copy of your master production db. These two .df files will then be identical. When you have df changes to make create the incremental df between the development db and the master. Use that same incremental .df for *all* updates to all production databases.

Obviously there is a lot more to change management than this but you have to start somewhere and this is the problem in front of you.

 

[StoneKeeper]

Re: create incremental .df file produces updates for char fields that want set decima

okay, of course you are right.

We will start to manage this in a better way. Thank you for your support and knowledge.

regards

 

[rzr]

Re: create incremental .df file produces updates for char fields that want set decima

Yes, we do something *very* similar. But we also make sure that not everyone has access to this "master-dev" database to make schema changes. All schema requests will be routed to a one-pt contact - so no one else is making un-necessary / random changes during development process.

 

[StoneKeeper]

Re: create incremental .df file produces updates for char fields that want set decima

Tom, i am doomed since ages ;-) But so far, it works for us in this way. As rzr sad, it is important to manage the requests during developement.

btw: i found and applied one solution for the original problem:

1) small script find the fields in db with 0 instead of ? in _decimals

2) create incremental .df file based on 1) with "update decimal ?" commands

3) load .df into db

4) recompile is not necessary

5) next incremental compare works l


This solution uses the "official" way to change the dictionary and is very fast and handy - even for production systems.

regards

 

[TomBascom]

Re: create incremental .df file produces updates for char fields that want set decima

Sure, that works.

But doing development in production and reconciling changes by comparing production systems is not a long-term success strategy.