Without changing column name, I need to get around a reserved keyword 1

[breezett93]

Hello

I am creating a program that pulls out records if a certain criteria is matched. In this case, the criteria is the column, Class, matching a particular code.

Unfortunately, the original creator of the table must not have known that Class is a reserved keyword, and it's causing issues in my program.

Here is a brief bit of my program:

DO WHILE .NOT. EOF()
	IF A->CLASS = "Z8"
[indent][/indent]//Copy record to different table
[indent]ENDIF[/indent]
ENDDO

I'm looking for a solution that allows me to not have to rename the column which could break other programs utilizing this table.

Is there a way to give an alias to a column like a table?

Thanks

 

[Mike Lewis]

the original creator of the table must not have known that Class is a reserved keyword, and it's causing issues in my program.

What issue is it causing?

In general, there is no serious harm in using so-called "reserved words" as field names. In that sense, they are not really "reserved". It's true that using these words as field names is bad programming practice, but it should not lead to errors - at least, not in the scenario you described.

To verify that, I just did the following:

CREATE CURSOR testr (f1 c(12), class C(12))
APPEND BLANK
REPLACE class WITH "xyz"
? test.class = "xyz"
? a->class = "xyz"

Both ? commands gave the expected result.

So what problem are you seeing?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[breezett93]

The program just hangs with a blank white FoxPro background. I can press escape to cancel. Then this message pops up:

Called from - \\location\etc\etc\program.fxp

No error messages, and I opened up the fxp to just double check. There was lots of gibberish text, but the reference location was correct.

I opened up the debugger, and the program is fine until it reaches the if statement. So that made me think the problem was using Class.

This is the whole thing:

SET EXCLUSIVE ON
CLOSE ALL DATABASES
SET SAFETY OFF

Select A
Use \\*****************\table.dbf

*Scan the file

DO WHILE .NOT. EOF()
	IF A->CLASS = "Z8"
  		Copy To \\*****************\table2.dbf
 	ENDIF
ENDDO

Quit
Return

 

[JRB-Bldr]

The program just hangs with a blank white FoxPro background

Unfortunately that, by itself, doesn't help us much.

You appear to have the code.
So, with that in mind, what have you done to line-by-line Debug the code in order to see what is causing the program to 'hang'.

Have you run the program from the Develop environment and looked for it to 'hang'?
Have you Activated the Trace Window and put a Breakpoint just before the suspected code and run it?
Or, instead of a Breakpoint, have you put a SET STEP ON just above the suspected code and run it?

Good Luck,
JRB-Bldr

 

[Mike Lewis]

From what you have described, I think it's highly unlikely that the problem is caused by the use of Class as the fieldname.

A more likely culprit is the COPY TO command. This command creates a new file. But you are doing that in a loop. The first time, it will probably work OK. But the second time, the target file (table2, in this case) will still be open, so Windows (not VFP) won't let you write to it. I don't know why VFP isn't detecting that situation, but it does look like that is what is happening.

To verify that, I suggest you temporarily remove the COPY TO command. In its place, just do something like [tt]? A->Class[/tt]. If that runs without any problems, that will confirm what I am suggesting.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I see no SKIP in your loop, would it help to SKIP 1 in the DO WHILE loop right before the ENDDO?

If A would be an object at the same time m.A->CLASS would refer to it's class property, but A->CLASS still addresses the CLASS field of workarea A.

Like Mike asked, what happens when single stepping through the code? Can you see an endless loop effect? Do you ever leave the While loop?


Even if there is no anniversary of the SCAN..ENDSCAN loop around, I'd say you should celebrate it by introducing it in your code and only use FEOF() in the future, if you work with low level file functions. Use EOF() only, if you want to check whether a RELATION finds no row in a child table or to check if a REPLACE will work. Even after LOCATE or SEEK you can ask FOUND() instead of !EOF(), which is much more intuitive.

SCAN..ENDSCAN does not only do the SKIP for you, it even knows in which workarea to do it, even when that workarea is not currently selected. It's really a mature iteration of a workarea, and tested in time, there is no need to avoid it any more now, since you also can be sure no future VFP version will break it.

If you like your WHILEs you can SCAN WHILE !EOF(), but don't forget to forget the skip, or should I say skip the skip? If you SKIP 1 in a SCAN WHILE !EOF() loop, you'll only process odd rows and skip even rows, if you know what I mean.

Bye, Olaf.

 

[Olaf Doschke]

On the topic of what you intend to do...

Select A
Use \\*****************\table.dbf

*Scan the file

DO WHILE .NOT. EOF()
	IF A->CLASS = "Z8"
  		Copy To \\*****************\table2.dbf
 	ENDIF
ENDDO

To copy a single record only, you'd rather need SCATTER/GATHER or you COPY TO ... FOR RECNO()=x, but COPY TO is not really what you'll want. you don't add rows via COPY TO, you always create a new file - with all the problems Mike mentioned.

If the first record of table.dbf contains "Z8", you copy it fully to table2. In that COPY TO operation you move to EOF and leave the loop. That is your only chance you ever got out of that loop.

Bye, Olaf.

 

[Dan Freeman]

This does sound like a terminal loop.

That's one of the reasons I wouldn't use DO WHILE/ENDDO. I'd use SCAN/
ENDSCAN.

 

[Mike Lewis]

I completely agree with the others re using SCAN/ENDSCAN. But, Breezet, please also note what I said earlier about the COPY TO command. I feel sure that is the root of your problem - and in any case is the wrong command for what you want to do.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

Please excuse my ignorance; what does the A-> mean or do in the above application?

Regards,
David

 

[Olaf Doschke]

David,

The "->" is simply an old and still valid alternative for the dot, eg workarea->column is the same as workarea.column and object->property the same as object.property. And the A simply is the workarea here, you can address workareas 1 to 10 with letters A to J, so these letters are working as third alternative to the workarea number 0-10 and the full alias name.

breezett93,
All you may want is

SELECT * FROM table WHERE class="Z8" INTO TABLE table2

SQL is the better way to work with VFP today.

A non sql way would be:

use table.dbf
copy to table2.dbf for class="Z8"

Bye, Olaf.

 

[David Higgs]

The "->" is simply an old and still valid alternative for the dot

Thank you for the explanation.

Regards,
David

 

[dbMark]

Years ago we had a table with a field named "NAME" which worked fine for years until we included it somewhere, in a class as I recall. The property class.name conflicted with the field NAME and so we had to change the name of the field. After all these years I don't remember whether we tried including the table alias when in the classes but we probably tried that and failed, hence the field name was changed. Evidently some reserved words really are reserved and key.

 

[Olaf Doschke]

Well,

even inside the class the property name would need to be addressed THIS.NAME, but an object named like a table alias, ie an object reference in a variable named person and with property name would need to be addressed m.person.name to not mean the person.dbf name field via person.name, if a person.dbf is open with a name field. It's still possible, as is with the property name and field name class. It's the same type of problem. Even in a situation in code between WITH THIS ... ENDWITH the addressing of .Name differs from addressing the Name field without a dot, so if you apply m. everywhere you read access a variable you're safe to not mean a field. The only confusion is in this direction, ie you want to address the property and get the field value.

This behaviour even is by design and wanted, if you SCATTER MEMVAR and create variables named like the fields intentionally. You still can see through to the fields, as access to them has priority over same variables.

Any field name could have such a collision with a variable name, not only in the namespace of reserved words, so not using reserved words is no big safety. It just makes things less complicated, if you don't have any overlap with commands or function names or other keyword like options or for example the strongly SQL related words FROM, JOIN, WHERE, HAVING or such words, which are not even a commanand themselves.

But the universality of any names makes avoiding any name collisions quite impossible, unless you speak three languages and define code in english, table and field names in spanish and variables in german, for example. And even then there is a chance of overlap.

Bye, Olaf.

 

[breezett93]

Thank you all for the replies, and sorry for the delay in replying.

The problem did appear to be an infinite loop, and it has now been fixed. All the Z8's are getting pulled.

Thanks again!