Changing schema for compiled app.

[freak]

Using 9.1d... I have an app supplied by a vendor which is all .r files. I need to change the length of a character field now. Can I simply modify the field or will the app throw a fit because it was compiled against a certain size field? I've done this numerous times for .w apps but never for .r apps.

 

[TomBascom]

Changing schema formats does not impact r-code.

(You could easily test this with some sample code and the "sports" database.)

 

[freak]

I seem to remember that if I change an index I get some type of a checksum error and need to recompile. Do I remember correctly? Does that only apply to indexes?

 

[TomBascom]

That depends on your version of Progress. For ancient, unsupported and obsolete versions like 9.1D yes, it probably impacts r-code. For more modern releases you can add indexes without any impact (of course the r-code won't use them but it won't object to them either).

In any event -- you cannot actually "change" an index. You can add a new one, drop an old one or rename one. To "change" one you add a new one with your changes, drop, or rename the old index, and then rename the new index.

 

[freak]

Thanks for your help and all the adjectives!

 

[TomBascom]

My pleasure

 

[tamhas]

BTW, take note of the qualification in Tom's response ... even when you are allowed to change the schema without forcing a re-compile, don't expect the existing r-code to pay any attention to the change. It pays attention to those things at compile time and only pays attention to the CRC signature after that. If you have a compiler, but no source for the application, you can write new code which will pay attention to the change, but for the old code you will need source.

 

[freak]

I need to lengthen a character field. I am hoping the app will use the extra length of the field. I'm going to set up a test database when I have a chance.

 

[tamhas]

Test and verify, but keep your expectations low.

You do recognize that the format defined in the schema is only the default which an application uses if it is given no other instructions. It does not limit what can be put into the field in any way. You can put 3000 characters in an X(10) field as long as the application will let you get it there. But, conversely, if the field is defined as X(200) and the screen where you are entering the data has a field defined as X(10), you are only going to be able to get 10 characters into that field from that screen.

Your .r code will have resolved the field widths as a part of the compile. It will have either used the default from the dictionary or a value specifically provided in the program or the global defaults by field type, but whatever it used, it used it then. To change that, you need a fresh compile or a different program.

 

[freak]

This is a packing slip field that is limited to 10 chars. From the form the user can deal with making the number shorter to fit if need be. Behind the scenes we have a receiving program that creates receipts automatically. If it can use the full width I'd be happy. Testing is certainly the key here.

 

[tamhas]

If you have control of, i.e., source for the receiving program, you can happily stuff as many characters in there as you want ... without touching the DB schema.

 

[freak]

I have the source but the data field is defined as x(10). I want to change it to x(50).

 

[tamhas]

Fine, give it a format of X(50) in that program. Then you are done. No need to touch the DB at all. As I said, the dictionary format is just the default which is used if you don't specify a different format in the program. E.g., it is common to define a field which is updated in an editor widget and thus might be very long with a dictionary default of X(80) or something so that a quick and dirty program can list at least the beginning of the content. But, for the actual I/O, it is what you specify in the program which will be used. Specify nothing and it will come from the dictionary. Specify nothing in the dictionary and the default for the data type will be used. Specify something in the program and that will be used. Enjoy!

 

[freak]

Will the format in a compiled app truncate the data if it exceeds 10 chars. The packing slip is copied to a transaction table that a format of x(10).

 

[tamhas]

The display will depend on the format in the individual program. If the picking slip formats to X(10) and there are 50 characters in the field, then you will only see 10 of them. If you try to edit the field in a program that is X(10), you will only see the first 10.

Try a couple of tests with simple programs and explicit formats. All you need is
define variable x as character initial "123456789012345678901234567890".
display x format "X(10)".

 

[freak]

I understand the impact on the displayed data. We can live with that. What I'm concerned about is "can the format effect an assignment?" I place 50 chars in this field (with my prog that I have the source to) that is formatted x(10) on the screen and I verify that all 50 chars are there. Then later the _compiled_ app assigns the data to some other table (which may be default x(10) also)... will all 50 chars be assigned or will the format x(10) effectively truncate it?

 

[tamhas]

Assignment pays no attention to format. Only display. If you display that 50 character string on the screen and let someone edit it, I'm not going to guarantee what you will end up with. But, if you read 50 characters from the DB and assign it to a field in a new table, all 50 characters will be there. Nowhere in ABL is there a sense of what gets stored is limited for any datatype except the maximum sizes and the decimals attribute of the decimal datatype.

 

[freak]

Ok... That was what I was hoping for! Now I just have to deal with the display issues only. Thank you for relentlessly helping me!

 

[tamhas]

Well, good luck. The horrible thing about not having source is that there is no way of telling whether some clever programmer has stuck in a gratuitous X= substring(y,1,10) on you where you can't see it, so you obviously will have to test this all the way through the process flow of the application, but there is no reason why it can't work, without schema changes, other than the possible human factors aspect of not being able to see the whole thing.

One might wonder about someone needing a 50 character PO number, but that is a whole different issue!

Feel free to contribute to my rep points ....

 

[freak]

Well, good luck. The horrible thing about not having source is that there is no way of telling whether some clever programmer has stuck in a gratuitous X= substring(y,1,10) on you where you can't see it, so you obviously will have to test this all the way through the process flow of the application, but there is no reason why it can't work, without schema changes, other than the possible human factors aspect of not being able to see the whole thing.

I've mapped it out pretty well I hope!

One might wonder about someone needing a 50 character PO number, but that is a whole different issue!

It's not a PO number it's a packing slip number. 20 would probably cover it but I've had so many issues with the 10 they gave us I started talking big.

Feel free to contribute to my rep points ....

Gave you everything it would let me!!! Thanks again!