James,
Try this:
#include "fivewin.ch"
#include "adordd.ch"
REQUEST ADORDD, ADOVERSION
FUNCTION Main()
RddRegister("ADORDD",1)
RddSetDefault("ADORDD")
/*
SET ADO TABLES INDEX LIST TO = expressions used to build queries with ORDER BY clause. Here you can even use sql expressions like ASC DESC CONVERT etc
SET ADODBF TABLES INDEX LIST TO = standard clipper like expressions to enable functions like Indexkey() to work. These are the actual indexes you re using in your app
array spec :
{ {"Table Name", {"tag name","index expression"},;
{"2nd tag name","index expression"} },;
next table... }
*/
//change tag name to custid as your previous post
// as in clipper you cannot have repeated index (tag) names.
// you can try {"COUNTRY","COUNTRY DESC"} to check behaviour
SET ADO TABLES INDEX LIST TO { {"CUSTOMERS", {"CUSTID","CUSTOMERID"},;
{"COUNTRY","COUNTRY"} } }
SET ADODBF TABLES INDEX LIST TO { {"CUSTOMERS", {"CUSTID","CUSTOMERID"},;
{"COUNTRY","COUNTRY"} } }
SET ADO TEMPORARY NAMES INDEX LIST TO {"TMP","TEMP", "TEMPORARY" }
SET ADO DEFAULT RECNO FIELD TO "HBRECNO" //needed always to be indicated and exist on the tables!
SET AUTOPEN ON //your choice!
SET ADO FORCE LOCK OFF // required ahf why?
//isnt the path to mdb needed?
SET ADO DEFAULT DATABASE TO "northwind.mdb" ;
SERVER TO "ACCESS" ;
ENGINE TO "ACCESS"
USE customers
dbgotop()
SET ORDER TO 1
xbrowser fastedit
SET ORDER TO 2
dbgotop()
xbrowser fastedit
INDEX ON SOMEFIELD.... TO temp1
SET INDEX TO TEMP1
xbrowser fastedit
//try also this
sele 0
USE "INFORMATION_SCHEMA.TABLES"
xbrowser fastedit
Return nil
It seems we have to make lots of changes with indexes to use SQL.
No James the beauty of it is that is very easy to work with indexes maintaining exactly the same way of working as with any other rdd.
The only thing we need to do is to indicate these SETs to ADORDD we dont change anything else in the app code.
I didnt test this myself because I dot have ACCESS right now. Im only working with MySql.
Once more please note that the indexes are not being physically built in SQL engine these are only used to build ORDER BY clauses when opening the tables (recordsets) with SELECT....
We should not interfere in the database logic that is for DB ADMIN to do.
If later the DB ADMIN gets to the conclusion that many selects are using a certain ORDER BY clause may be it would be worth to build a true index at the server to serve faster those requests but this should never be done at the app level.
Please let me know if its ok now.
