HreadSeekFirst(FileName,KeyName,Keyvalue,HwriteLock)
While not Hout(Filename)
//get some other data and do some stuff
Hmodify(FileName)
HreadNext(FileName,KeyName,HLockWrite)
End
Has anyone suggestions to do something like this in a more efficient way in a HF C\S environment?

This is the classic example that will not perform well under HF C/S. But the answer to your question lies in what "do some stuff" means.
If you can specify the stuff to do, somebody can probably give you an idea how it might be optimized under C/S.

Hello Wim,
your test of 10000 index-sequential reads is not ideal for testing a client/server data base. The basis of a C/S database, are queries. The moment you introduce a selection criteria, queries will perform better than loops and filters. However, if your application is based on integrity constraints, you can’t use queries since they don’t respect them. In that case, C/S will show performance benefits for searching data on complex selection criteria.


dsSQL is Data Source
vQuery is string = "select count(KEY_ARTICLE) as TotNum from ARTICLE where GROUP_ARTICLE = 123 "
if hExecuteSQLQuery(dsSQL, vQuery) then
hReadFirst(dsSQL)
info(dsSQL.TotNum)
else
info(hErrorInfo)
end


vQuery="Update ARTICLE set MODEL='Test' where GROUP_ARTICLE = 123 "
is probably more efficient in C/S than a loop. It should modify 10000 records faster than the 6 seconds of HF Classic. The problem is locking because HExecuteRecord doesn't do it. If you really need it, you might be better off using views which allow locking and writing modifications via hViewToFile. Alternatively, you could use transactions but a mix of records locked by HRead... commands and modifications by an update query is rather unpredictable.
When looping through all of a file, HF C/S databases are at a disadvantage. An alternative when using selection criteria, according to someone in a French forum, is the following:
HSeekFirst(ARTICLE, GROUP_ARTICLE, 123)
WHILE HFound()
hRead(ARTICLE,hCurrentRecNum,hLockWrite)
ARTICLE.MODEL="Test"
HModify(ARTICLE)
hNext(ARTICLE, GROUP_ARTICLE)
END
the difference is that the above searches the index and only reads those records that correspond to the selection criteria. It probably won't have an impact on your original test since all records are included, meaning the same 20,000 accesses.
Regards
Mat

//Read 10000 records:
HReadFirst("ARTICLE","KEY_ARTICLE")
WHILE NOT HOut("ARTICLE") AND i <000
i++
HReadNext("ARTICLE","KEY_ARTICLE")
END

....
//Modify 10000 records
HReadFirst("ARTICLE","KEY_ARTICLE",HWriteLock)
WHILE NOT HOut("ARTICLE") AND i <000
i++
ARTICLE.MODEL="Test"
HModify("ARTICLE")
HReadNext("ARTICLE","KEY_ARTICLE",HWriteLock)
END
On HF Classic reading 10000 records took about 0.4s, in HF C\S about 1.1s
On HF Classic reading and modifying 10000 records took about 6s, in HF C\S about 51s

We have an application running over a network with the .exe on the
server. We use a lot of hReadfirst() and hReadseekfirst(). Correct me if i'm
wrong, but are you saying that it is, in our case, useless to switch to C/S??

When you mention queries, you mean queries produced by the WD-Query editor or
SQL-queries?

If you send back a HModify, that's another 10,000 trips across the LAN, a total of 20,000 trips.
With C/S the object is to send one command to the C/S database and let it do all the work.
For a C/S database, instead of the code above you would use something like this:
SELECT * FROM FileName
One trip across the LAN for the request, one trip back with returned data.
I am not a SQL guru by any means, but I think if you try something like an UPDATE command it may work faster. See "UPDATE (SQL language)" and "Creating an update query" in the WD Help file.

should also have said that it depends what hReadSeekFirst commands are used for. Originally, I mostly used them to read individual records for creation / modification. All tables, combos and lists were filled via queries. Due to desperately slow multi-file queries in HF Classic, I started using single file queries, plus a FOR ALL loop on the query and a HReadSeekFirst for each record in the query result to obtain values from other files, e.g. output of all pending orders via query and getting product description and customer names via hReadSeekFirst. Under HF Classic this is much quicker than linking 3 or 4 files in a query. In HF C/S it's the opposite: a query linking all files is quite quick and multiple hReadSeek in a loop will slow down the process. As far as I know each HReadSeek is converted into a query. So, it's easy to work out that if you have 1000 records in your result and search data from 3 other files, in the worst case, HF C/S has to execute 3000 queries inst!