code4 to code5 in dbf file

[slobodan1949]

Code4-to-Code5
Maybe someone else will need:
I had a problem with customer codes that have 4 characters: "0001" to "9999"
The user requested the ability to form many more customers than 9999.
Increasing the customer code from "10000" to "50000" required major changes in
application database and in the application itself. The solution was to enroll
customer codes greater than 9999 will be coded with 4 characters.
It was solved as follows:

* Implemented in Xbase++ using ot4xb.dll/lib/ch
* Convert a WORD numeric value into a hexadecimal string
* cW2Hex( nW ) -> cHex

aNiz:={}
for i=(30960+10000) to (30960+10030) STEP 1
cHex := cW2Hex( i )
AADD(aNiz,{i,cHex})
next i
Return:
10000 ---> A000
10001 ---> A001
10002 ---> A002
10003 ---> A003
10004 ---> A004
10005 ---> A005
10006 ---> A006...

Documentation for this technique is provided in the file: code4-to-code5.zip
Autor: Dragan Blagojević - Blagoje

[Tom]

Hi.

Needing more space for data is an issue we all have/had once in a while. I remember we had a name field fixed to 15 characters of length, and as the first customers came with longer names, we already had tons of functions cutting all kind of strings down to 15 characters or placing strings inside strings and other funny things. So, we added a second field "nameadd" and used that for longer names, while searching for names was internally still using 15 letters. Nobody ever complained about that, but it was not a very good style. There still maybe stuff left from that. Uuuuh.

Someone we all know once said on a conference: "One of the most important principles in programming is: Think of the future!"

So, maybe it was helpful in your case what you did and your solution is useful for others, but I want to promote taking the harder route. Change your code, change your databases, do it the right way, and think of the future. Do the monkey work once and be comfortable for the next years. Don't add fields if the fields you have are too short and don't code numbers wrong in order to wide the range your app can represent.

Besides:

10000 ---> A000

This is confusing at first glance. "10000" is "3E8" in hex. I understand your approach - all numbers up to 9999 stay as they are (so no need to change them in all other tables), all numbers above are a mix of hex (first digit only if there are five digits) and dec. But this leads to problems in the future, I bet on that (and it only works if the numbers are stored as characters). At the time, I was very happy with our solution with the additional field. Some month later, I started hating it.

[rdonnay]

"One of the most important principles in programming is: Think of the future!"

As we get older, it gets harder and harder to think of what the future holds for us.
One of my customers is trying to sell his financially successful business, but buyers only want to hear "web based".
When he started this business, that future was unimaginable to him, and it still is today.
He has a much bigger problem than coded numbers.

[Auge_Ohr]

hi,

Attachment in this phpBB Forum does not work

The selected attachment does not exist anymore.

please use CODE Tag to release, Thx

[Auge_Ohr]

hi Roger,

found out that i can download Files from this Forum when use this Syntax

Code: Select all

http://bb.donnay-software.com/donnay/download/file.php?id=2145

instead of (wrong)

Code: Select all

http://bb.donnay-software.com/donnay/phpbb3/download/file.php?id=2145

so "/phpbb3" is to much in URL which are show for Attachment

[rdonnay]

found out that i can download Files from this Forum when use this Syntax

http://bb.donnay-software.com/donnay/do ... hp?id=2145

Jimmy -

That is very interesting. Thank you for that tip.
Now I need to see if I can change the PHP code with that fix.

[Tom]

As we get older, it gets harder and harder to think of what the future holds for us.

"The future" is everything from "tomorrow" up to "in ten billion years". But today is always today. Encrypting single digits in order to widen the range is a today-solution. It may be a smart and clever solution, but it comes with a new limit. Changing the code in a way that field lengths just don't matter anymore is a better solution. It doesn't matter if the world ends tomorrow, but if not, it will save time and work for some months or years.

We all don't know what happens tomorrow. In germany, investment companies run around and buy all kind of software companies in the healthcare-business, no matter what technical base they are using, from Xbase++ via Microsoft Access via .Net to Angular. It only depends on the business they are in. A friend of mine started a business two years ago (not in the healthcare world) and his software is using the most advanced techniques you can imagine. But noone wants to use it. He just got "the call" from his bank two weeks ago.

"Thinking of the future" is not the same as clairvoyance. Nobody can do that.


Edit/add: Besides this, we all know that web-based software is the future, and we know that since more than ten, fiveteen years. It's not a surprise. Surprisingly, desktop based software is still in use, it still gets sold, depending on the market you're in. But it's not a technological investment anymore.

[Victorio]

hi,
when i must change length of database field, I use automatic update structure by pattern dbf which updated with every newer version of application. but i must also manually change dialogs, browsers etc. in source code . maybe solution will be once invest more time and modify application to recalculate all browse column size, get dialogs with say, get fields etc by this pattern database. in future only replace pattern dbf and need no change any in program source code.
also in this pattern dbf is also field with number and date version application from which was this pattern distributed.
some problem is with update structures in exclusive access.