Visual FoxPro 9 CursorAdapter - cannot open cursor 2

[carolx]

I created a cursor (native) ctransactions using the cursoradapter class. If I try to open it as a table I get the message ctransactions.DBF does not exists. Why is this?

 

[Mike Lewis]

Because you can't open a cursor as a table. The whole point of a cursor is that it is temporary. Once you close it, it ceases to exist. So you can't subsequently open it.

The point is that the cursor is already open after you create it. So you can just go ahead and do whatever you want to do with it. Almost all the VFP comnmands that work on tables also work on cursors. (USE is an exception, for the reason stated above.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[DSummZZZ]

Just to add to Mike's comment, ctransactions.dbf doesn't exist, but the cursor exists as a table until it is closed. It just has a temporary file name in the 'temp' directory. As an example: C:\USERS\DSUMME~1\APPDATA\LOCAL\TEMP\0000270P00FK.TMP
I have actually had a need to re-used a cursor in apps. You can reference the temp table as follows:

CREATE CURSOR bob (field1 c(10))
USE DBF('bob') AGAIN ALIAS fred IN 0

-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[carolx]

Thanks for the help. What was happening is that a routine opened a table twice. The cursor is referenced in the same routine, so I had to adjust it to exclude cursor. I wasn't familiar with the format USE DBF('xxx'). What I do is open a copy of the underlying table for cursoradapter cursors instead. I will file this for reference since it can be used with any cursor. Thanks again.

 

[Olaf Doschke]

Well, if a cursoradapter is having a DBF as it's data source, so if the datasourcetype is native, the cursoradapter doesn't differ much from a local view or a direct query, it automatically opens the DBF in a workarea. You should only work on the cursor only, nevertheless. Depending on buffering and locking set it will automatically lock both the cursor records/header and the DBF records&header when needed. You can interfere with that, if you work on the DBF itself, too.

But if ctransactions is a cursorname, ctransactions.dbf surely doesn't exist for the reasons already given. DBF() is just the function return the table file. In case of cursor there also is one. In most cases it doesn't exist on HDD, though, it's a virtual file, cursors mostly exist in memory, unless they get too large and need to be swapped to HDD. That's even true for cursors you create with CREATE CURSOR, you don't create DBF files, but virtualised files. Virtualised in memory, not the kind of virtualisation introduced by UAC, which is rather redirection than "real" virtualisation (kind of a weird adjective for virtuality, but I think you know what I mean).

For VFP the file DBF() exists, and so you can USE DBF('alias') IN 0 AGAIN, which also was the workaround in VFP up tp VFP6 to make cursors created as query results writable.

That doesn't address your initial problem though. You don't open a cursoradapter, nor it's cursor. You create a cursoradapter instance, or the dataenvironment does, when you put a cursoradapter into the data environment. The cursoradapter cursor is generated by calling cursoradapter.CursorFill(). It's automatically created, if the data environments AutoOpenTables is set .T., because that triggers the cursoradapter.AutoOpen method to be executed, which in turn causes CursorFill().

You work on the cursoradapter cursor, that's what it's for, you don't reopen that cursor, you requery it, if you need a refresh or you generate a further cursoradapter. Each cursoradapter should have it's own uniqie cursorname specified in it's Alias property, or things will of course get messy.

Bye, Olaf.

 

[Olaf Doschke]

Also read about SET EXACT (which by the way has no influence over query string comparisons but explains VFPs string comparison) and SET ANSI (which affects queries).

Bye, Olaf.

 

[Olaf Doschke]

Sorry, wrong thread.