Abbasaif,
let's get this very straight, as this obviously is very slowly getting to you. I'll take my time to show you all this and hope you'll get a final understanding.
Startup VFP, close down all windows but the command window and put that on the right side of the screen, so you can see the output on the left side.
Type in
and ENTER it. Yes, that's more digits than usual, it's intentional, just go with it, you later see why I used this.
We also need
(or any number between 0 and 25)
Now let's compare the recommended expressions. Not all of them, just the latest solutions which were given after some misinterpretations have been cleared up.
Mike's latest tip (translated to the variables used in this session) was:
Code:
? LEFT(mJono, 8) + CHR(65 + totrec)
That outputs [tt]JO123456
A[/tt], because a) it only takes 8 characters and then adds one with CHR(). As totrec=0, it follows [tt]CHR(65 + totrec)=CHR(65 + 0)=CHR(65)='A'[/tt]. The stress of Mikes solution is on generating the A, not changing from JO to RO.
Can you please understand this, can you please see the value of Mike's hint, that he gave you code that can replace the whole >50 lines of code you used with a single expression? The stress was not on using LEFT() instead of SUBSTR(), the stress was on using the totrec number within CHR(), so you don't need to cover 26 cases of code.
If you can't even see what is helpful about something it becomes extremely hard to help you.
I said you already had the better idea about using SUBSTR(), but that doesn't mean it's the better idea overall, it's better than using LEFT(), because LEFT does obviously start at the first position and doesn't remove the 'JO', but notice it's the right length, it only takes the 6 following digits after the JO. There you have the first reason I intentionally used a too long code [tt]JO]1234567889[/tt], to show how LEFT removes the unwanted ones. With SUBSTR() you are better than that because you start in the third position. Let's see what your code does
without any of the +'A' to +'Z':
outputs [tt]
RO123456
78[/tt].
Now ask yourself why it ends in 78. You're thinking wrong about SUBSTR() parameters. thinking it'll extract from position 3 to 8, but that's not the case, the 3 is a position the 8 is a length. The intellisense help also shows that to you, while you type in that command.
The right way to use SUBSTR would be:
I hinted back on the earlier tip to use STRTRAN():
which outputs [tt]
RO123456
7890[/tt].
Yes, this also keeps too many digits at the end, but in case you start with the correct data this also is solving the change from JO to RO and it's only about that and it preserves what else you have. You can argue what's a better idea. It depends on the bigger picture and what happens in the future. I'll spare to dive into that, just notice that STRTRAN(mJono,"JO","RO") is very self-explanatory in what it replaces with what. Some will prefer SUBSTR as it acts on predefined positions and they prefer that. If you add more suffixes you might get into the situation JO is not just at the begin of the code. But overall STRTRAN(mJono,"JO","RO") is more intuitive, you can ensure it only does the first replacement with STRTRAN(mJono,"JO","RO",1,1) and no code is stable and future proof against any thinkable changes. STRTRAN() also is more intuitive to modify if the prefixes change and even become longer.
And again, look back please, this wasn't the only thing I said. I continued about how you simply add a suffix with the + operator. You took +"X" far too literal. It is common sense X stands for anything. It's something I can't tell you as it depends on so much. It wasn't obvious back then what you'd use to know which letter comes next, we talked about maintaining counters in a table of such metadata.
But is it hard now, to put together two partial solutions to one overall final solution? Please, now pause reading and think a bit about what would be a solution.
------------------
Some people often argue "Just give them what they need", especially with questions like yours. And this would be a prime example for them because it's all just about a small expression. Just note I see this as a prime example about why it's important to go into details. Nobody knows you'd COUNT TO totrec to determine the next suffix letter. It's not that specifically this COUNT that we don't know without you telling us, its using a separate table so it's easy to know which is the next letter. Especially now that you stated you'll never delete a record it's sufficient. But nobody can know that.
I also argue it's important because you already hint on how this all extends with even further suffixes and how you don't want to end with Z.
We're making assumptions about the parts you don't tell, assumptions that are most obvious and normal to us, we're not in your head, we don't know the full story and while a screenshot helps, it still doesn't tell data types or other technical information. Mike, for example, thought mJono or nNew was a number and used [tt]PADL(nNew, 15, "0")[/tt]. His post was after you posted the image, but look at the time stamps: 9 Dec 19 14:27 you posted the image you forgot initially, 9 Dec 19 14:35 Mike wrote his answer. He likely started writing before your post and as one writes the thread doesn't update, so he likely only saw this after his post.
Yes, it's really very detailed and observing to see that and take that into account, it has nothing to do with programming skills, too. But it's something everyone could see and besides all that never think anyone is writing anything in bad intentions.
Is this one of my rare rants? I hope it's recognizable I'm not simply ranting about any mistakes made. I also see your position, you're not able to come up with the necessary code and ask for help and nothing works fully.
But see, this is not about giving you 100% of what you need, nobody can do that in every case, as anything always has a context only known to the questioner. Even such simple things. And it's not asked too much you pull this together to a final conclusion.
Still not convinced, how this isn't simple and how it's always problematic to only hand out fish and not teach fishing?
Take this code and try to figure out why it doesn't work:
Code:
Create Cursor tmpjobs (jobno integer autoinc, jono char(15) default 'JO'+PADL(jobno,6,'0'))
Create Cursor tmpRoll (rono char(15))
Append Blank In tmpjobs
Insert into tmpRoll values (Strtran(tmpjobs.Jono,'JO','RO')+Chr(65+Reccount('tmpRoll')))
Insert into tmpRoll values (Strtran(tmpjobs.Jono,'JO','RO')+Chr(65+Reccount('tmpRoll')))
So, to be clear, this is not meant as the solution, this contains an intentional error and there are several ways to make this work. I'll come back, but I'll leave it to you to figure out one way of solving that.
Bye, Olaf.
Olaf Doschke Software Engineering
![[thanks]](/data/assets/smilies/thanks.gif "[thanks] [thanks]")
