Data Dictionary Update procedure

Whenever I make some changes to the database (ie. adding new columns, changing column type, changing column name) I run ito problems resulting manual update of the fields in the App.
Another words when I import changes to the DCT, then to the Apps old fields get overriden. This is a majo headache! I wonder if am I doing something wrong or there is some way of protecting fields in existing App from update.
Normally I would expect some (i.e FREZE) parameter which wil protect particular field from Dictionary updates. This is how it is handled in other 4GL tools.

I also do not understand the relation between: FORM -> Applications -> Synchronize - feature and DICTIONARY -> Synchronize Applications ?
Which has priority and actually why do we need it in two places ? Manual updates to GRID apps (when the table structure changes) is simply PAIN ON THE ASS!

I work with SC and those changes since SC5 but so far I’m really not happy with the whole concept as it is confusing and does not really speed up development a lot.

For example:
I have added 2 new columns to the table. I went to the DCT and run - “Synchronize Dictionary” then run “Synchronize Applications”
I know there is an option to select only new fields (those which I have added recently) but if one forget to do this the whole thing gets screwed up! Is there any method to protect it from happening ?

Could somebody who mastered that process please enlighten me ?

BTW: Question to NET MAKE - when will we be able to Synchronize grid Apps the same way we do Forms ???

Arthur

Arthur, AFAICFO (new term when working with or asking for support from Scriptcase “As Far As I Can Figure Out” LOL)

One of my applications require the use of the language files. AFAICFO the dictionary option to “Synchronize Dictionary” deal specifically with indexing the table field with the language file. For example, my db contains a table for employees. field1 = FName, field2 = LName etc. If I change, add or delete fields in the db table I must run the “Synchronize Dictionary” option in the Dictionary app so that my language index ‘knows’ what table and field(s) the form/grid is linked to.

However, HERE IS A PROBLEM with scriptcase… One that I have emailed to Carlos as well as posted to this forum…
IF I need to make significant design/layout changes to a db table (i.e. tblEmployees) when I “Synchronize Dictionary” my language file/index gets filled up with CRAP!! I have asked for a very simple fix… When Synchronizing The Dictionary, SIMPLY DELETE THE ASSOCIATED INDEX IN THE LANGUAGE FILE BEFORE CREATING/SYNCHRONIZING the dictionary… so the language file/index does not fill up with crap if I need to make alterations to the associated db table.

NEXT, IF I make changes inside my language file/index (i.e.) changing the ‘label’ ( lang_tblPersonnelCatalog_fld_emName [en] ‘Nick Name’ [sp] ‘Apodo’ [fr] ‘Surnom’ etc.) then it is necessary for me to run the dictionary option to “Synchronize Applications”.

IF you are NOT making changes to your db tables/fields, it does not appear to be necessary to run the ‘Synchronize Dictionary’ option more than once.
IF you make changes to the language file/index, you MUST run the ‘Synchronize Application’ option to update the labels in the forms/grid fields/display.

I hope this is helpful to you. Sorry if I misunderstood the question. It took me 30-40 hours to figure out the dictionary/language deal… When I FIRST starting working with the language files, the dictionary did NOT even work. Two years later… still no response from NetMaker (codeBraker) Scriptcase regarding any fix, patch or repair.

Good Luck!
Stu Buck
Phoenix, AZ

Yes I agree with all what you’ve said. I’m working with some other tool (building desktop Apps) which also uses Dictionary and it works excellent (though this tool exists on the market from the era of DOS) and is very mature although not perfect. Thanks to that I know what can be done and what can we expect/ request. The bad thing is that Net Make keeps implementing things that are not really important while crucial parts remain either unchanged or with bugs. Perhaps we should bring this on the webinars and ask official questions so at least more people are aware of the issues.

Arthur