I can only give you a partial answer - interspersed. You figure the rest from what the others say.
>Well I have to be honest, performance is not the ONLY reason that I would lilke to convert the APP to use SQL Server. This is an application that I resell. It was purchased from someone else that paid consultants to design and develop the app. It would look good ont he sales side to be able to say the app was developed with SQL Server as none of the compitition is. I guess what I am really looking for is some sort of list of data related operations in FoxPro and what will and will not work with SQL.
Any commands with SQL syntax should be easily portable into SPT commands (i.e. using Sequel PassThrough), if that's what you plan to use. If you want to use remote views, you can use them just like you'd use buffered tables. Of course, this may mean that at times you may cause too much traffic to the server and it may even be slower than dbf - if you're pulling a complete large table with all the memos, for instance. If you use parametrised views or SPT cursors, you can fine tune your data access to take advantage of the server without pulling too much down the cable.
>For example, do the SEEK and SCAN commands still work?
They'd work on the view or the cursor - which you must index first if you want a SEEK. But then if it's a parametrized view or cursor, the seek will find only the records that are currently in the cursor, not the rest.
> Should I be binding all my combo boxes to cursors? That sort of thing.
Depends on what you've bound them to so far. If you've bound them to tables, you may just pull a SPT cursor from the same table, give it the same alias, sort it the way you did before, and if you do this before the combo instantiates, you may not need to touch the combo at all.
Generally, you need to decide whether you'll use remote views, cursor adapters or SPT or what - a lot of things would be done differently, depending on this decision.
> Where it become appropriate, I will redesign the table, indexes, and the way the data is retrieved. But for the most part, I just need a starting point - and I think that point it to identify what commands work and do not work under SQL. So far I am in the middle of re-designing the login system. I was amazed how many tables were accessed before the login
>screen. The login screen was where I wanted the user to select the SQL Server, Database, and username/password combo.
Looks like you're getting into refactoring at the same time... which may get you into redesigning both the dbf and sql system. That may complicate matters.
