STRU - Lists and modifies the structure of the dbfs files

[Pablo César]

Sorry for delay
( It was too late in time and I was too tired yesterday )

No problem, my friend ! Everybody needs to rest and it is very important to do it, we work much better !


Yours pictures Mr. Esgici, are so very nice shown !

Speed of progress too is satisfactory

I have seem that you have tested with 15044 records, OMG !

By the way, if you will like I want to participate your big work with a little function : produce an unique file name for avoiding rename with same name the original file.

Yes be free, show us how it could become better... You means to modifying in second dbf/dbt files and keep original without changings ? Or you means about for translation demands ?

For translation, I intended to make thru .Lng files like us I made in DataHora.

.dbt file didn't backup'ed.

Wow ! Terrible, sorry.

Have you tested dear Esgici, button "Processos" ? You can make your own routine to convert data in runtime of importing data.

One of paradigms is that I personally I refuse to use MEMO type fields. These can of type thru dbt, can make corruptions and also it is not so practical way comparing my own method. I will explain...

I used to replace MEMOs fields with independent txt files for each record, which are stored in separated folder for particular proposes. I believe, not all records has its text as observations. Then you can created by any particular sequence number which will composes the nomenclature of file. Then this solution, does not interferes in databases of dbf files. This is my experiencies and I always suggest for this implements.

[Pablo César]

By the way, if you will like I want to participate your big work with a little function : produce an unique file name for avoiding rename with same name the original file.

Yes be free, show us how it could become better... You means to modifying in second dbf/dbt files and keep original without changings ?

If your suggestion, had been this (to make struct-changings not in original file). Let me understand how it could make influence in all STRU behavior:

1. I believe, different name must be done when make change in a second file. My suggestions is eg (Let give name just for example practices):

Original dbf file name: Clients.dbf
Resulted file name: Clients_New.dbf (when MEMO filed is present, Clients_New.dbt)

2. When is selected a dbf file (Clients.dbf) for modi stru, then all changes will be done in another file with name Clients_New.dbf and (when MEMO filed is present, Clients_New.dbt). But when finished importing data dor second target file, STRU which one must be in use ? Clients.dbf or Clients_New.dbf ?

3. This second file (Clients_New.dbf) must be saved in current folder or in the folder where the original dbf file is ?

I liked your idea, in case, because I could not need to open in EXCLUSIVE way to make modi stru. Original file, could be open in SHARED way. And there is no needing of make file backup before applying structures modifications, because all changing is going to be done in one dbf created in separated. I was thinkig when you started mention about this question, thank you collegue for this valious tip.

[esgici]

Olä Pablo

You means to modifying in second dbf/dbt files and keep original without changings ?

No, a bit different:

We have Clients.dbf, user modified its structure.

1. Build a temp table file with new (modified) stru and USE it.
2. APPE FROM Clients.dbf
3. Make a "old" file name as : Clients_old.dbf
4. If Clients_old.dbf is exist, try Clients_old_2.dbf
5. Increment this sequential number until a file with this name un-exists.
6. Apply this name to rename original Clients.dbf.
7. If Clients.dbf have "M" field(s), rename .dbt ( or .fpt ! ) with produced new name;
( If Client_old_2.dbf, rename it with Client_old_2.dbt ( or .fpt ! ).
8. Rename temp file ( and its memo file ) to Client.dbf ...

I hope that I had explicate my POW.

I guess that you didn't tried Modify Table process of DBA. If you will try, please apply structure modify process on any table for several time, to see what I work to say.

Of course, decision is yours. If you say "user will use my program under his/her own risk" all my speech is useless.

in case, I could not need to open in EXCLUSIVE way to make modi stru. Original file, could be open in SHARED way. And there is no needing of make file backup before applying structures modifications, because all changing is going to be done in one dbf created in separated. I was thinkig when you started mention about this question, thank you collegue for this valious tip.

In this case, after modification process, user will be enforced to using Client.dbf under Clients_New.dbf name and IMO we haven't such right.

In other hand, following my scenario have a little different benefit : until actual renaming process, original table may left SHARED. Only a very short time will be close it and rename.

Saludos

[esgici]

I have seem that you have tested with 15044 records, OMG !

Yes, IMO better test is harder one

For translation, I intended to make thru .Lng files...

This is a good news.

Have you tested button "Processos" ?

Sorry, no yet ( you know, language difficulties )
And I want before applying some other tests

One of paradigms is that I personally I refuse to use MEMO type fields...

I always respect personal POWs; but as a friend, not as a user
I agree some problems about MEMO type fields. But we can't wait same opinion from all users

Salodos

[Pablo César]

No, a bit different:

But the following STRU is doing part as well you said.

Please note my explanation (in blue color) according your texts.

We have Clients.dbf, user modified its structure. Ok

1. Build a temp table file with new (modified) stru and USE it. But STRU in actual version is already doing this, creating dbf.tmp file and with modified fields.
2. APPE FROM Clients.dbf I not using "append from" because for differences of data types which could be no compatibles with changing proposed and original data in.
3. Make a "old" file name as : Clients_old.dbf This I have done, little different (in actual version STRU names for Clients.bkp). But It will be considered as better nomenclature proposed. I means rename name and not extensions how I used. In your way I will able to include .dbt or ftp files
4. If Clients_old.dbf is exist, try Clients_old_2.dbf Do you think it is so necessary to keep all changings ? It will demands for many files, because each time I confirm to save, then will needs to make another copy. IMO to keep first original as backuped will bee enough. But shall be before of any changing, really first time of changing.
5. Increment this sequential number until a file with this name un-exists. Yes, is easy to do it.
6. Apply this name to rename original Clients.dbf. It´s the big question ! Keeping original name but aply structure modifications. Right ? In this version, this ois happing in this way
7. If Clients.dbf have "M" field(s), rename .dbt ( or .fpt ! ) with produced new name;
( If Client_old_2.dbf, rename it with Client_old_2.dbt ( or .fpt ! ). Yes I understand, .ftp files must be laso considered in backup option. Then I will do this, but not with many versions. I think is undeed.
8. Rename temp file ( and its memo file ) to Client.dbf ... Renaming or copying. In this actual version is copying. I think is the same effect.

I hope that I had explicate my POW. Yes, my friend thank you very much for your great ideas and critical replies, very useful.

I guess that you didn't tried Modify Table process of DBA. If you will try, please apply structure modify process on any table for several time, to see what I work to say. But seems that in DBA you can not change for diferent types, because it is saying in my try: "Can´t Apply ! There is type mismatch." But in STRU, it is possible !

Of course, decision is yours. If you say "user will use my program under his/her own risk" all my speech is useless. Ohh no ! I think we can colaborate with much as possible to avoid any lost.

in case, I could not need to open in EXCLUSIVE way to make modi stru. Original file, could be open in SHARED way. And there is no needing of make file backup before applying structures modifications, because all changing is going to be done in one dbf created in separated. I was thinkig when you started mention about this question, thank you collegue for this valious tip.

In this case, after modification process, user will be enforced to using Client.dbf under Clients_New.dbf name and IMO we haven't such right. Alright. Original name must be keeped even with modifications

In other hand, following my scenario have a little different benefit : until actual renaming process, original table may left SHARED. Only a very short time will be close it and rename.Yes I understand this. But now STRU already does in very short time the copy of new structure and data.

Have you tested button "Processos" ?

Sorry, no yet ( you know, language difficulties )

Ohhh you need to see ! When you ckick in "Processos" button, you can apply one specific rule or procedure to take the particular data of new field chenged. This you can write in xBase language.

In this process made by prg text file and being compiled in runtime, you can make to get from another third file to be located and repass to actual field. You can do this in each of all fields even been new or not changed too. it All will depends of you source code written.

Do you understand now ?

[esgici]

Olá Pablo

I'm glad that we are understood each other

At this point not left any points to talk about, everything is talked.

Only one : "append from" doesn't means always using APPEND FROM command; without this command it's possible appending data from a file (table or not) to another file (table or not).

Do you understand now ?

I'm not sure
Only a guess: probably all your users are skilled programmers

Saludos

[Pablo César]

I'm not sure
Only a guess: probably all your users are skilled programmers

OMG, It was not my intentions to dissatisfy you with my question. I thinking that you are not undertanding when you said: "I'm not sure". Please let me put in other words just for you and rest for understanding, please. I will give you an example for this uses:

1. Lets say that we need to change size and consequently data of field NAMES in Clients.dbf
2. It data must bringing only first name (for exemple)
3. Before changing size of this field with name of "NAMES", you can click in "Processos" button and then will open a window like this:

Screen36.PNG (13.48 KiB) Viewed 4719 times

4. Then you will save this editing codes (with this example) thru menu option "Arquivo" then "Gravar".
5. After this you can make efects clicking in "Salvar" button.
6. Open with your favorite DBF editor then you will see the field "NAMES" just with only first names.

Is it clear now ?

But in the other hand, programmer does not know how to make with data convertions: then I suggest do not use STRU for modifying structures. This is a tool for developers and all must know to do for working well... hihihi don´t you think ?

[Pablo César]

Release 3.4 correcting backup of dbt and fpt files. Now it is possible to select which RDD (DBFNTX or DBFCDX) to use when changing to MEMO field. Names of backup is composed by nomeclature of: dbf_name + "_old".

<Attached file removed. See messages later of this, with new release.>

[esgici]

Thanks Pablo

Good enhancements, please continue

User defined conversion "processos" not working yet, is this correct ?

I'm waiting for translation

Saludos

[Pablo César]

User defined conversion "processos" not working yet, is this correct ?

Ohh yes it is working ! As I mentioned at my previous message. Remember, you will need to make your own source code inside that EditBox and save your text with "Gravar" in menu item. Then you can "Salvar" just for apply modifications.