Assist w/deciphering STORE command variable

[CBaker208]

I've been assigned the task of deciphering some Clipper code with no Clipper experience. I've run into some code that I can't interpret - can anyone tell me what significance the 'AMOUNT+' variable has in the statement below? I can't tell if this is just doing addition or if the lack of the space between the variable and the operator has some other meaning. There is an AMOUNT field present in the input data table. Also, what would the value to MDEB_TOT be if it had previously been set to -55.25 and the value in the amount field was 25.00?

STORE AMOUNT+ MDEB_TOT to mDEB_TOT

Thanks!
CB

 

[JockMullin]

Hi CB

That statement could also be coded

mDEB_Tot=mDEB_TOT+AMOUNT

i.e. it is adding the database field AMOUNT to the existing memory variable mDEB. Spaces are not significant around operators. The STORE verb is used to signify the following variable is a database field.

In your example, mDEB would contain -30.25.

Jock

 

[JCreamerII]

As Jock said it is a pretty straight forward statement, mDeb_TOT would appear to be an accumulator, adding up the "AMOUNT" field in this routine. I have an older program that I work with and the STORE command is used to initilize memory variables with a constant and not used on FIELD's per se. The STORE command can be used with FIELD's or memory variables, but I prefer to use the statement mDEB_TOT = mDebTOT + AMOUNT, as Jock outlined. The spacing is irrelevent to the compiler, it's strictly for the user's own visual preference to push the fields and operators together or space them out.

Jim C.

 

[CBaker208]

Yes, that's the total that I came up with as well but it doesn't match up with the total printed on our report (86.25) which is just printing out the MDEB_TOT field. Here's a litte more info that might make the problem a little clearer:

Input data (table):
ACCOUNTNO AMOUNT
603 -55.25
603 25.00

Program:
STORE 0 MDEB_TOT
STORE 0 MDOCBAL

IF ACCOUNTNO < 1000
STORE AMOUNT+ MDEB_TOT to mDEB_TOT
STORE MDOCBAL + AMOUNT to mDOCBAL
ENDIF

@ LINE, 90 SAY MDEB_TOT PICTURE '9,999,999.99'
@ LINE, 118 SAY MDOCBAL PICTURE '9,999,999.99'

In one STORE statement the operator is right next to the variable and in the other it's got a space between - I don't know if this has significance and I've seen it used in other places in the code. Also, this is only place in the program where the MDEB_TOT variable is used (besides the initial STORE statement and the print statement).

Thanks for your help...

Cindy B.

 

[JCreamerII]

Cindy,

Does your program have a function to recreate an index. Are the -55.25 & the 25.00 the only values getting processed. As I mentioned in my intitial post, the spacing is irrevelent, the compiler just interperts the statement without the spaces. They are just for your readability. Can you query the AMOUNT values in the table to be added, try it with & without the index. If you have a function to reindex the table you may wish to try that first. If you can turn on the debugger you can trace the values that are getting added to MDEB_TOT.

Jim C.

 

[CBaker208]

The program does index in the input file and it does process other values, I'm just showing the relevent fields - this is a daily journal reporting program. The -55.25 & 25.00 are the only debit transactions being processed to produce the debit account total.

How would an index affect the value of these fields? I feel like there's something going on with the initial value of MDEB_TOT being positive and then 'assigning' the negitive value of 55.25 to it, followed by the positive 25.00. At first I thought that the sign was being changed by the 'AMOUNT+' variable - but that wasn't right. Basically the output appears to disregard the sign and simply add the absolute value of these fields.

I was trying to avoid having to put this in the debugger as I haven't used it and the code "seems" straight forward. Argh...

CB

 

[JockMullin]

Hi, Cindy

I gather account nos <1000 are debit accounts.

Are you sure those are the only such accounts in the input table? Your total of 86.25 is not the sum of the absolute values of the transactions you listed; that would be 80.25.

Are there by any chance any RESTORE statements in the program after the STORE 0 to mDEB_TOT statement? That could be restoring mDEB_TOT from a memory file (extension .MEM).

Other than that it would be good to see more of the program code, particularly the loop logic thru the input table.

Jock

 

[CBaker208]

Hi Jock,

Yes, the < 1000 are the debit accounts. I just created them again in the test system to verify that they are the only transactions, and indeed they are. The total was actually $80.25 not $86.25 as I said my previous post.

There are no RESTORE statements in the program at all. The total that is being printed is the MDEB_TOT not the mDEB_TOT. Kind of confusing but the mDEB_TOT is used later on in final report processing.

I'm thinking I'll have to put this thing into the debugger to figure it out. I may return to the boards for more assistance...I sure appreciate all the help.

Thanks!
Cindy B.

 

[JockMullin]

Hi, Cindy

OK, good luck with that.

BTW case is not significant in Clipper, so mDeb_TOT, Mdeb_tot,
mdeb_tot and MDEB_TOT are all the same variable. Many people follow coding conventions to make code more readable but the compiler doesn't care.

Jock

 

[CBaker208]

Hi Jock,

Thanks for the info re: MDEB_TOT and mDEB_TOT, I had been told that the small m indicated a "memory" variable and that MDEB_TOT was a completely different variable. This is an old system that is being replaced with a .net app. I'm trying to figure out what the old system was doing so that the new system can produce similar results.

Your info makes a difference - so case has no meaning in Clipper and apparently spacing doesn't seem to have much meaning, for instance, you could code:

aMOUNt+MDEB_tot=mDEB_TOT

and it would be interpreted the same as:

AMOUNT + MDEB_TOT = mDEB_TOT

Thanks for your help,

Cindy B.

 

[DTracy]

Cindy,

Case has meaning to the Clipper Pre-Processor. Be sure to inspect the .ch files in that module for directives, better yet do a compile with /ppo and look at the preprocessor output file.

Regards,
David.

 

[JCreamerII]

Cindy,

If an index is corrupt or broken the program may not see all of records in the file or it may see other records that shouldn't be included because of the damaged index. If the program has worked cleanly in the past and isn't working correctly now ( without a program change ) then that leaves the data and or index as the problem. I have seen this type of issue before when then index was broken, and an erase & recreation of the underlining indexes would correct the issue.

As I mentioned in my previuos post I would trace through the pocess, check the recno() of the records getting processed. That will tell you what the program is looking at, and should give you a clue as to where the problem is coming from.

Jim C.

 

[CBaker208]

Thanks to all for the assistance, this is a great message board.

I did figure out what was going on with the debit balance not matching up with the input transactions on the daily journal report. It turned out that the debit column on the report isn't actually reporting the total of the column. I know that sounds weird - and it's definately not a standard accounting practice but that's what was happening. The data I had expected to be included in the total was simply not being used.

Again, I appreciate all of your help; JCreamerII, DTracy & JockMullin!

Cindy B.