PLEASE.. forget about DBF's ( although I'm using them with no problems in ALL my products ), you can't compare SQL to DBF. not even ADS.
But you forget; ADS IS SQL.
SO knowing how to manage a DBF is worthless in order to work with SQL,
With ADS you can work ISAM and SQL in the same app... so nothing is worthless.
I've done incremental searching with Mysql, Paging, Scipting.. and I don't use hundreds of lines.. just ADO features and STANDARD SQL.
I don't think so my friend.
Ok, so you have a 250k records table. And you what to display the full table to do an incremental search. As you type the bar moves to the nearest record. For argument's sake let's say you are displaying 250k customers with their address and telephones. It is ordered alphabetically. You type "R" and the bar moves to Ramos, then you type "i" and the bar moves to Rivera, then you type "o" and the bar moves to "Rios"... Or better yet, after typing the first "R", press the up arrow key. You should move to something like "Quesada". And you do with with 250k records using SQL ... I don't think so. In order to imitate an incremental search you would first have to fetch the whole table: "Select * from customers", load that into a memory array (or use the returning cursor) and now you can do the incremental search, or you wait for the first keystroke ("R") and you execute "Select * from customers where lastname between 'Ra' and 'Rz'" and now display that on a browse. In the last case, you are not display the whole table, so forget about moving up with the arrow key to anything previous to the first "R" last name. This is ok when working with a web app. But for a win32 app..., very limiting. There! the power of ISAM.
...if you want to keep working with dbf's, but it can't be compared to SQL, and DBF LOGIC is quite oldfashioned. ADS Local is not Transactional.
Old-fashioned... hum... So is RDDs but boy they are so much faster than any .net or ADO or ODBC or any of them combined. That actually give small shops like ours an advantage. Nothing is faster than DBF/CDX ( or ADS/ADI for that matter).
There's no HOSTING offering ADS, you'll have to mount your own server to have it working.
Now, that's a good point. You are taking about web access. You are right here. Not only that, you do have to recompile php if working with a linux server. If you are developing web-apps exclusively and no win32 apps to touch the data from within the LAN... well that's precisely where sqlite is recommended.
ADS 5 users is sold in 844€ ( better no ask for a 25 user )
I'm quite sure that my customers pay around $500 for a 5 user and $5,770 for 250 users (that's US dollars).
So IMO for large amount of users.. go SQL.
Right. And ADS is SQL.
About SQLITE, perfect, SQL for small LANs, all the knowledge on SQL can be used on any large DB, a completely UPTODATE knowledge.. and with ADO... better... you can use ADO with all WEB programming languajes.
No different than ADS; which is my point. With ADS you can use ODBC/ADO/.NET/php/Java/Perl...
If ADO will disappear with new Windows Versions....
I'll tell you what will disappear: RDDs! (if user support continues to withdraw).
Thank you for your reply. I'm not taking merits away from SQL set based transactions. I'm very happy I was introduced to SQL and pleased with its results. BTW- I did it by using ADS and slowly changing some parts to SQL. I was not up to completely re-writing my apps. Your comments are quite in tune with my own. My point is that (1) ISAM is also a good thing (2) ADS is the only SQL with ISAM combined and (3) The local version is free and the client-server version (especially for 250 users) is worth paying for.
There is a ADS FWh user in Chile -
Patricio. Do you know him?
Reinaldo.