Hi Phillip
It occurs to me that in your scenario you could do as follows:
a) In the init event of your form, remove the recordsource from all 10
grids:
thisform.pageframe1.page1.grid1.recordsource = ""
etc (one for each grid on each page)
b) put a method to create a cursor adapter by code in your form (you could
call this method "adapter")
c) in the load event of your form, put this code to open your database
Local cDBC
Set Multilocks On
cDBC = c:\data\data.dbc && I assume your DBC is data.dbc and sits in
this folder
If Dbused(cDBC)
Set Database To (cDBC)
Else
Open Database (cDBC)
Endif
In this manner, your data base is open and ready for your cursor adapters.
d) every time the user clicks on a page in your pageframe, the activate
method of the page should do something like this
thisform.pageframe1.page1.grid1.recordsource = "" && if you clicked on
page 1
thisform.adapter(1) && the parameter tells the method that it should
fire the code for the first grid
thisform.set_grid(1)
Set_grid method
lparameter pnOption
do case
case pnOption = 1
with thisform.pageframe1.page1.grid1
.recordsource = 'firstcursoradapter'
.column1.controlsource = 'firstcursoradapter.field1'
.column2.controlsource = 'firstcursoradapter.field2'
etc
endwith
case pnOption = 2
etc
endcase
the deactivate method of that page should remove the recordsource of that
page's grid
thisform.pageframe1.page1.grid1.recordsource = ""
Now, the adapter method:
lparameter pnOption
local cCmd,
do case
case pnOption = 1 && for the first grid
cCmd = [select ]+transform(thisform.nMaxRecordsThatCanBeSeen)+[
from salesordertable ] etc.etc.etc
case pnOption = 2 && for the second grid
etc
endcase
You make one specialized select command for each one of your grids. And use
the corresponding code to fetch only those records that you can see on the
grid at any one time. It is a bit complicated, but should be very fast.
In general, you should only bring back from the data source those records
that the user can see at any one time, and then, if she wants more records,
bring another batch. In a grid you can see about 20 to 30 records anyways.
As for the seek, it is possible to index a cursor generated by the cursor
adapter, provided you remove its inherent buffering and then put it back
into buffering.
When I create a CA from code, I always use buffering 5 (optimistic table
buffering). To index the cursor I do this:
local nBuffering
nBuffering = CursorGetProp("Buffering")
If nBuffering > 1
CursorSetProp("buffering",3)
endif
index on &indexkey tag &indextag
If nBuffering > 1
CursorSetProp("buffering",nBuffering)
endif
But then, you would only be indexing a very small amount of records, the 20
or 30 you fetched.
CA's are great to replace views, I use them all the time.
Maybe these articles can help you.
From this one, you can see how to build a CA in code
http://www.utmag.com/wconnect/wc.dll?9,7,10,2089
And this one will show how to bring just a few records for your grid
http://www.utmag.com/wconnect/wc.dll?9,7,10,2126
Regards
Rafael Copquin
www.copquin.com.ar
Universal Thread Magazine - Translation Coordinator
Treasurer - Microsoft Users Group of Argentina (MUG)
www.mug.org.ar
----- Original Message -----
From: "Philip B" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 22, 2006 3:43 PM
Subject: Re: VFP and SQL Server : CursorAdapters
Thanks Mike and Aílsom,
I do have the fetch property set to -1.
The problem I have is not completely understanding how to retrieve more
records from the original cursor.
My screen has 10 pages on it with 10 grids (1 on each page)
Each grid represents a different set of data from my sales order detail
table.
So, I created a CursorAdapter in the D.E. that initially opens the Sales
Order Detail table from the SQL Server, pulling all valid SO records.
I then create temporary tables for each grid pulling only certain classes
of items (10 distinct classes).
I need these temporary tables because I allow the user to interactively
change the sort order by clicking on the header of each column to resort
each grid as well as interactive searches on each column...
My limited knowledge tells me to then make the cursoradapter for the Sales
Order Detail table pull all the records so that I can pull the different
groups from its results into each temp table.
How could I pull the different groups for each temp table if my initial
results are just 100 records in the cursoradapter?
The other caveat is that I need to update the cursor adapter for changes
that are done in each grid...
(Sorry for the long post...)
Philip
Ailsom F. Heringer (Osklen) wrote:
Philip B escreveu:
I'm just now getting into using the VFP 9 CursorAdapters on a form using
the ADO data connection to an SQL 2K Server DB.
Question I have... is there anyway to put indexes on the CursorAdapter
in order to use the seek() function rather than LOCATE ?
Or, is there a better way to SEEK using a method on the Adapter ???
Also, is there a more efficient way to open the adapters? It's taking
so long to open, I have them set to retrieve all records because I need
all the records to produce some temp tables that are in Grids on the
screen... I saw the option to only retrieve 100 or so records and Fetch
as needed... how can I make sure I pull all the records from the
CursorAdapter when I perform an SQL-Select from the cursor tied to the
adapter into a temp file??
T.I.A.
Philip
If you really need to use SEEK and indexes, you can create the indexes at
the AFTERCURSORFILL event. But I suggest that you edit the SELECTCMD
property to return only the row that you need from the table. And if you
really need to get all the records, set the property FETCHSIZE to -1.
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
