GeofS


The <form>.Load() code below, which used to work fine with VFP6, now generates a syntax error (Error #10) after compiling with VFP9. The error occurs on the OpenTables() line. It occurs with multiple forms, all of which have their AutoOpen and AutoClose properties set to FALSE. What has changed to break this simple code


local lReturn

with this

if type('.dataenvironment') = 'O'
* make sure the data is portable to another system
.SetFormDataSource()

* open all the data for the form's data environment
.DataEnvironment.OpenTables()

lReturn = .lDataEnvironmentLoaded
endif

endwith

return lReturn






Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

CetinBasoz


Probably there is a syntax error in SetFormDataSource method.






Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

GeofS

The SetFormDataSource() method looks okay to me, plus it compiled fine in VFP9, and compiled and ran in VFP6. What's more, if I disable the line that calls SetFormDataSource(), the program still complains of a syntax error in the OpenTables() call.

I can't figure out where to look for the offending code.






Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

Naomi Nosonovsky

Can you put set step on in this method and trace it in the debugger





Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

CetinBasoz

Maybe then you have code in OpenTables.





Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

Tamar E. Granor

FWIW, I think I'd be testing with:

IF PEMSTATUS(This, "DataEnvironment", 5) AND NOT ISNULL(This.DataEnvironment)

rather than TYPE(). Don't know if it would make a different here.

Tamar




Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

GeofS

I've tried running this app interactively and starting the debugger. I've tried putting DEBUG and SET STEP ON commands in the methods I want to debug. I can't seem to find a way to get the debugger to show me what's going on in the methods causing the problem. I can start the main PRG in the debugger and run for a while, but the program runs into operational difficulties in interactive mode and can't find some resource files that it needs, so it quits. All in all, a very frustrating situation.




Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

GeofS

Yeah, that's what I thought, too. But there's no code there.

Thanks for trying.




Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

GeofS

Since this is an inherited app, I don't want to change any more code than I have to. And I think you're right... The problem is caused by something in the OpenTables() method. When I found no code in the method itself, I tracked the culprit to the views being requeried in a custom data object for the tables used on the form. I got rid of the 'syntax error' by trial and error - the SQL SELECT statement in the view referenced two variables that weren't defined yet. Apparently, VFP6 didn't care but VFP9 does.

Now I'm contending with an "Error #107 - Operator/operand type mismatch" message generated by a different view. The code shown in the message is "Select agent.*, .f. as marked from cits!agent where .T. into cursor Viewcalv62". I'm not sure this is even the statement that's generating the error. Do you see anything wrong with it Do you have any advice on how to ferret out these statements that used to work in VFP6 but now don't work in VFP9

I'm going to put this away for the night and take some painkillers for the "beating my head against the wall" headache.

Thanks for any words of wisdom you might have.




Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

CetinBasoz

That code have no offending syntax as I see it. I think it is again something in the underlying view. Try using:

select * from cits!agent

outside form to check if that operates alone right. Its SQL might give some clues.

PS: where .t. is for creating a true cursor You can use nofilter instead (and it would create a true cursor due to added ".f. as marked" even w/o a nofilter).





Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

Tamar E. Granor

If this is really a View definition, it shouldn't include an INTO clause.

Tamar




Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

GeofS

I don't know where the INTO clause came from; I assume that the system added it to the definition for the view that it was trying to generate.

Almost all of the Local Views definitions begin with a SELECT statement like the this one:

select client.*, contact.first, contact.last, contact.work_phone,.f. as marked from cits!client left join cits!contact on contact.contact_id = client.maincontact_id where &cWhere &cOrderBy

There are a few that don't have the "where &cWhere" and "&cOrderBy" clauses. The ones that do have those clauses cause a syntax error when I try to open them for modification, and they refuse to be saved until I get rid of those clauses.

I don't know if this situation is related to the errors I described in earlier postings of this thread, or if it's something different that I ran across in trying to fix the other problem.

Any ideas

And thanks to all of you who have offered suggestions.

Geof.




Re: VFP6 to VFP9 broke Dataenvironment.OpenTables

Tamar E. Granor

To open those views, you need the corresponding variables (cWhere, cOrderBy) to exist.

Tamar