STRU - Lists and modifies the structure of the dbfs files

[esgici]

Hi Pablo

I guess that we are in a misunderstanding, because we are need a third language for understanding each other; and personally I don't know this third language sufficiently

Please be calm, our histories not quite different. I meant like you, me too I'm in the beginning of learning root of HMG.

Anyway, your program is quite good, educative and useful; please continue to develop.

Happy HMG'ing

[Pablo César]

I guess that we are in a misunderstanding, because we are need a third language for understanding each other; and personally I don't know this third language sufficiently

Probably...

Internet communications, in write way, used to be very cold and most of time, the person in the other side, could understand according his mood... in the way the person is. Not always is exact expressions. You also, have confessed that you can not participate in portuguese forum (for example) due the language, so there is this more complication with it. So, I agree, we need to cool our head... but I wish your suggestions, ideas and participations of it to help me become better app, ok ? Thank you for your good understanding.

Returning to tech details in STRU:

And now I am implementing another button option which is gonna give us a chance to make "process" in runtime mode (with xBase code) of each importing data of each field. I means, when is creating or even changing a field, you can do your own routine to take the right data for each field.

what do you think about it ?

[esgici]

Hi Pablo

I'm glad to the consensus

Returning to tech details in STRU:

And now I am implementing another button option which is gonna give us a chance to make "process" in runtime mode (with xBase code) of each importing data of each field. I means, when is creating or even changing a field, you can do your own routine to take the right data for each field.

what do you think about it ?

Designing a form for editing a table structure is an easy task; open a grid, fill it with structure info, wait modification will make by user, until a "done / apply" button pressed.

The 1.st difficulty is validating user input: field names must be upper-case, field type must one of predefined types (CDLNM), width and decimal position values must match with types, standard widths ( 8 for D, 1 for L, 10 for M) must suggest by program and can't change by user etc.

If user defined a "new" field or didn't include an existing field, no problem, this is a situation easy to implement.

The 2.nd difficulty is bigger: and arise when user changed properties of a field without changing its name: how will convert types to other and how will modify other properties according to types without losing user data?

For example :

D type changed to C : DTOC()
C type changed to D : CTOD() does already recorded C type data is a properly convertible to date ? fe: does field with is 8 ? If no, what can be do ?
N type changed to C : STR() What about decs ?
C type changed to N : VAL() What about decs and commas ?

If decreased field width ?

if changed a L type field to one of others and vice versa ?

In short : Since we have five different types, we have at least 5^5 probabilities, some are easy to implement, some are not

As a result, it's almost impossible to develop a resolution to satisfy everybody

However, these type of difficulties are challenge and a programmer haven't any possibility to escape form theme

Saludos

[Pablo César]

Thanks for your evaluations Mr. Esgici. Very impressed in short time your criticals demands made by you. Very much appreciated !

1st difficulties, I think is already done.
2nd difficulties, I agree with you that quite impossible to get a right result in convertions. At begining STRU makes it own convertions according user definitions, of course is subjected to obtain a error or bad data in emigration. But for this reason I will make an optional "process" which STRU will be applied, according source codes be implemented and this will be directed identified by each field. Another interesting thing in STRU, that name or sequence been changed, it will take in accordingly.

I shall do it from monday this implementation and I think will gives more strengh in data convertions, but will be needed programmer source codes quality and his own consciousness what is doing (for own risk).

Anyway STRU makes a copy in the first changing, which allow user revert all changings of database in case of bad data convertions or bad re-structuring.

[esgici]

Hi Pablo

Thanks for your evaluations Mr. Esgici. Very impressed in short time your criticals demands made by you. Very much appreciated !

1st difficulties, I think is already done.
2nd difficulties, I agree with you that quite impossible to get a right result in convertions. At begining STRU makes it own convertions according user definitions, of course is subjected to obtain a error or bad data in emigration. But for this reason I will make an optional "process" which STRU will be applied, according source codes be implemented and this will be directed identified by each field. Another interesting thing in STRU, that name or sequence been changed, it will take in accordingly.

I shall do it from monday this implementation and I think will gives more strengh in data convertions, but will be needed programmer source codes quality and his own consciousness what is doing (for own risk).

Anyway STRU makes a copy in the first changing, which allow user revert all changings of database in case of bad data convertions or bad re-structuring.

Fully agreed

I will wait eagerly the result of your works.

By the way, renaming original table instead of erase it may be a good precaution.

Saludos

[Pablo César]

By the way, renaming original table instead of erase it may be a good precaution.

Yes understand. But in STRU makes first a copy before modfying other extension file-name (bkp in place of dbf). Then makes a temp dbf with changings and then copy overwriting original dbf. But if original dbf is open in READONLY or even EXCLUSIVE then this changing will not be take effects. In all cases, users must takes for own risk this modi stru and provides backup before anything IMO.

[Pablo César]

Release 3.3 with option to create your own prg and execute routine for migration data to a new structure. This process are compiled and execute in runtime, which can give more flexibility to create a individual routines for each field. Was corrected an error when replace Memo types and also make universal format for BBCode to TABLE format. Include HMGforum to locate as second site when need top make new topic with tables from clipboard.

[Pablo César]

You are welcome Mr. Esgici ! Let me know your opinions about this new "Process" option.

[esgici]

Olá Pablo

... Let me know your opinions about this new "Process" option.

It's a bit difficult for me; because of language restriction

Anyway I'm working to understand ...

Saludos

[esgici]

Olá Pablo

A "mini" problem :

.dbt file didn't backup'ed.

Saludos