Thanks Rafael and Andy for your comments.
They are helpful in my project...
Philip
Rafael Copquin wrote:
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.
