Is gather any different in vfp than foxpro?

[JulieAB]

Hi all

I am converting an old foxpro 2.5 app to vfp version 7. I did not write the original application which has absolutely zilch in the way of comments and documentation.

I have found a situation in three different programs in the application where the old code runs fine in foxpro, but bombs in vfp on gather statements. I am trying to figure out if there is something different about the gather (and scatter) commands in foxpro and vfp that may be causing this problem.

An example of one of the gather statements causing the problem is:

gather from per fields per1, per2, per3, per4, per5, per6

The error I get is variable 'per1' is not found

Based on my understanding of how the gather statement works, the table that is selected at the time that the gather statement occurs should have the fields per1, per2, ..., per6 in it. In my case, the table selected does not have these fields.

Any help or advice you all could give is much appreciated.

Thanks,

Julie

 

[Mike Gagnon]

JulieAB

I'm not sure but try removing the spaces between the field names.

gather from per fields per1,per2,per3,per4,per5,per6

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[JulieAB]

Thanks for your response Mike.

Actually, there are no spaces in the command itself. I added the spaces inadvertantly when I copied the command into my post.

Thanks, Julie

 

[bobmpalmer]

Julie

Apart from the addition of the NAME ObjectName clause no differences I can see. What is your associated SCATTER code?

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Mike Lewis]

Julie,

Depending on the logic of the program, it might be possible to leave out the FIELDS clause completely -- in other words, omit the word FIELD and everything after it.

The point is that GATHER will only pick up the fields that are actually present in the record, so in that respect, the FIELDS clause might be redundant. On the other hand, maybe the original programmer had something else in mind when he wrote it, so I can't say for sure if this solution would work.

To answer you general question: No, GATHER has not changed in this respect. There are some new clauses, but these shouldn't affect what you are trying to do.

By the way, are you sure that the record does indeed contain a field called Per1, and that the relevant table is open in the current work area? Sorry if this is stating the obvious.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[JulieAB]

Hi Bob,

Thanks for your response.

There is no associated scatter command in this program. The closest thing I see to it the select statement I listed here:

select b.empl, 9999 as per1, 9999 as per2, 9999 as per3, 9999 as per4,;
9999 as per5,9999 as per6,9999 as per7,9999 as per8, 9999 as per9,;
9999 as per10, 9999 as per11, 9999 as per12,9999 as per13, 9999 as per14,;
9999 as per15, 9999 as per16, 9999 as per17,9999 as per18, 9999 as per19,;
9999 as per20, 9999 as per21, 9999 as per22,9999 as per23, 9999 as per24,;
9999 as per25, 9999 as per26, 9999 as per27,9999 as per28, 9999 as per29,;
9999 as per30, 9999 as per31, 9999 as per32,9999 as per33, 9999 as per34,;
9999 as per35, 9999 as per36, 9999 as per37,9999 as per38, 9999 as per39,;
9999 as per40, 9999 as per41, 9999 as per42,9999 as per43, 9999 as per44,;
9999 as per45, 9999 as per46, 9999 as per47,9999 as per48, 9999 as per49,;
c.empname;
from budget b, employee c;
where b.empl = c.empl;
into dbf (tempfile);
group by b.empl;
order by b.empl

does that give any helpful clues?

thanks, Julie

 

[JulieAB]

Hi Mike

thanks for your response.

No, actually, the table does not have a field called Per1. That is what is so weird about it. It seems to work fine in foxpro though. Maybe vfp is just more specific and if the field does not exist, the statement bombs but foxpro ignores perhaps the missing fields?

thanks, Julie

 

[Mike Lewis]

Julie,

. Maybe vfp is just more specific and if the field does not exist, the statement bombs but foxpro ignores perhaps the missing fields?

I think that's probably the answer. You can probably safely remove the FIELD clause. However, be cautious. The fact that the original programmer included a clause which pointed to a non-existing field might be a signal that something more fundamental is wrong.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[JulieAB]

Thanks to Mike and Bob.

I think Mike hit the nail on the head regarding more fundamental problems. After further investigation, it turns out that in all three cases, the wrong table was the active table at the time of the gather statement. In each case a table was selected that did not have the fields it was trying to gather in. Once I figured out what table should be selected and made sure that was actually the one selected at the time of the gather statement, it seems to be working fine.

I am not certain how it works in the old version of the software. For right now I have come to the conclusion that foxpro was more forgiving than visual foxpro, and those gather statements were not needed at all.

Mike said "The fact that the original programmer included a clause which pointed to a non-existing field might be a signal that something more fundamental is wrong."

I appreciate your input a lot. It really helped me work this problem out.

Regards,

Julie

 

[CDavis]

Julie,

It looks like you have figured out the answer to your origninal question but I thouht I'd add something that wasn't included in any of the original discussion.

In looking at my old commands and reference books it appears that the "Gather From per" statement may have been referring to values in an array called "per". You might look to see if the array is being created. I know that I've had some trouble in the past in migrating old Foxpro code to VFP when I was using arrays.

CDavis