Cursor problem after copy to command

[cibe86]

Hi to everyone!!
I have a problem with my visual foxpro application that I can't solve...

I have a cursor named mycursor which I create with
CREATE CURSOR mycursor (FieldA N,...)
Then I make an insert like this
INSERT INTO mycursor;
SELECT * FROM mycursor2

mycursor is also bounded to some fields (ControlSource = mycursor.FieldA) in which I show to the users the values of the cursor and in which user can edit these values.
I don't need to store these values.

I use these values for making some elaborations and everything is going right until I make these commands
SELECT mycursor
COPY TO mypath

The files are created correctly. But after that the fields bounded with the cursor doesn't show any value and command like this
MESSAGEBOX(VAL(mycursor.FieldA)) show 0. Also the elaboration that I made now doesn't works.

I'm thinking this could be a problem of buffering because if I make a BROWSE after the copy command the problem doesn't appear.
I've tried to set
CURSORSETPROP('Buffering',1)
to mycursor without results.
Also a refresh to the field dosn't work.

Any help is appreciated, thank you !!

 

[Mike Lewis]

Yes, it does sound like a buffering issue. You are right to set buffering with CURSORSETPROP(), but it looks like you are not executing TABLEUPDATE(). You need to do that to commit the changes to the cursor. If you don't, the COPY command won't be aware of the changes, so they won't reach the the new table.

Excecute TABLEUPDATE() after the user edits but before the COPY. See the Help for details about the parameters that you need to use.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

I just read you post a bit more carefully. You are setting the buffer mode to 1, which means there is no buffering, so you don't need the TABLEUPDATE() after all. Sorry - my mistake.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[foxincloud]

COPY TO mypath
sets the cursor to EoF()

what about
GO TOP
?

 

[Mike Lewis]

Are you sure you are checking the correct values?

You say you do MESSAGEBOX(VAL(mycursor.FieldA)). But that has got nothing to do with the COPY command. You are looking at the values in the original cursor. Are you sure that's what you want?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

foxincloud has made a very good observation. COPY copies all data and therefore sets record pointer in your cursor to EOF, where reading cursor.numericfield always is 0. So this exactly explains what you see.
You should go back to the record you left before COPY. GO TOP may not be a solution, only if you have one record.

Often you can remember the recno and GOTO that recno, but in buffer mode this isn't a solution, as buffering means you have a temporary negative record number, until you leave it and get the real record number, which means you won't find the record you left. The only real good way to go back to a record is via remembering it's primary key value and then go back there, you can eaasly add a int autoinc field and that will be filled with a non changing value in any case.

Bye, Olaf.

 

[foxincloud]

GO accepts a negative recno:

create cursor Test(test I)
CursorSetProp("Buffering", 5)
insert into Test values (1)
clear
local nRec as Integer
nRec = Recno()
? m.nRec && -1
copy to array aa
? Recno() && 2
? Eof() && .T.
go m.nRec && m.nRec is negative (see above)
? Recno() && -1

 

[Olaf Doschke]

foxincloud. Fine!

But you didn't get the most important part of what I said: The record get's its real positive recno, if you leave it in record buffering mode. No record then has the negative record number you remembered and GO could go to a negative renco, no record has this record number anymore. AND you can't predict what positive recno you get. In a cursor that's easier, as it's local and exclusive, but in general I'd always only work with IDs.

Bye, Olaf.

 

[Olaf Doschke]

forgot a word:
>No record then has the negative record number you remembered and GO could go to a negative renco, no record has this record number anymore
No record then has the negative record number you remembered and while GO could go to a negative renco, no record has this record number anymore.

This is the central reason to use primary keys everywhere, even in cursors.
I could tell you stories about inherited code using nRecno=RECNO()... do anything... GO nRecno. Buffering is not the only "enemy", also SQL Server tables not having a recno at all. When "do anything" involves requerying remote data you get totally differ recnos in the vfp cursor....

If you just add a little bit of work to add a primary key field to each table, view or cursor and you always remember that value and SEEK back to it, you'll never go wrong, even if that is oversized for a cursor with just one record. But as said, with one record only you can simply GO TOP or GO 1 or just 1.

Bye, Olaf.

 

[cibe86]

Hi and thank you for your replies!!

foxincloude has right, the problem is solved if I make a GO TOP after the COPY command
I didn't notice the cursor was in EOF and since my cursor is only one row the GO TOP command is enough!

Thank you all!