Hi Bob,

>Just to put in my two cents. (since you are asking)

I did not ask :)

>1 I find myself using sql selects all the time - and glad I do. learing the sql language is - in my opinion, is a benefit that you will enjoy for years to come. the sql syntax is not going away.

I never said that.

>Add to that, using select - to create joins, for reports, and picking lists, is MUCH faster than using set relation to - set skip to and those old xbase type commands.

This is not true. Setting up relations is much faster (in terms of performance, not coding) than using joins, especially when using large tables. Performance problem however, can occur when you filter the related tables with SET FILTER.

>Personally I find working with cursors since they are on the local machine much faster in general, that working with only a network file share..

Before you'll have all data into a cursor you've generated the same or more network trafic than with SET RELATION. However, if you're planning to scan through the cursor more than once (e.g. printing a report multiple times) cursors can have a performance advantage because they reside on your local workstation.

>I agree with Mike, on the use of replace.

>in the long run, if you have to at sometime merge your data to sql server - getting to understand the sql syntax now. has no speed drawbacks, (that I can tell) and only the benefit of more powerfull querries... and so on.

SQL is a powerfull set of commands, no doubt, however SQL - Server and xBase commands are by no means mutual exclusive. Since the results comming back from the SQL-server are stored in local cursors or views, there is no objection to use the good old xBase commands like SEEK, REPLACE, DELETE etc. In fact when using buffering on those cursors and or views, you'll have no other choice than using xBase commands as SQL does not see buffered changes.

>Once I started using sql type commands about a year ago. I cant think of very much code which I use with seek anymore.

In terms of performance, SQL is much and MUCH slower than SEEK() to search a single record. Further SEEK() has characteristics that SQL-SELECT does not have: SEEK in combination with SET NEAR allows you to easely search for the closest matching record, SEEK does respect filters, SEEK can use filtered indexes, INDEXSEEK and KEYMATCH offer even further performance tuning.

However, when gathering info from tables in all sorts of variaties SQL SELECT is the clear winner of both. It easy (compared to the alternative), compact, clear and (most often) the fastest way to construct a resultset (e.g. for reporting).

Bottom line. Do not underestimate the power of xBase commands like SEEK(), REPLACE etc. They are record oriented opposed to SQL commands which are set - oriented. Therefore xBase commands, when used properly, can have a tremendous performance advantage over SQL, especially when dealing with the current record (Set oriented languages do not know the concept of current, next or previous record).

I find VFP such a beatifull tool, because it basicly has the best of both worlds: A terrific set of record oriented DML commands (xBase SEEK(), LOCATE, SCAN, REPLACE, DELETE, etc.) and a fairly good support for SQL commands. This allows me to choose for the most suitable solution in a given case.


My fl 0.02


Walter,