Ed,

>When I write things in my data services layer where I anticipate the need, you bet. Of course, this is only an issue with the native file system; with a backend, I don't know or care what gets opened and how the server manages things when I get a read-only dataset back for reporting. YMMV.

>Again, a read-only cursor is inherently a snapshotting of the data, and the locking issues are handled at the backend. A VFP SQL Select is also handling the locking behind the sceens for you. One less thing to screw up badly.

I don't know what you exactly mean by saying the VFP SQL select handles locking, but the SQL select statement definitely does not lock the table. During a SQL SELECT command the data of the involved tables can be modified in another session or on a another workstation. Therefore there is no guarrantee that the VFP SELECT is giving you an exact snapshot of one particular point in time. The only workarround you've got is to lock the involved tables with the FLOCK command, before the SQL command is started and release it after it has finnished.

>>If you switch data-engines you'll have more serious other things to take care of than a few simple reports. Adjusting your reports is peanuts IMO.
>>
>
>You miss the point - if I code the report right in the first place, in a manner that is not sensitive to the backend (and is at least as easy to do, if not easier) I don't have the problem at all, even when I change engines. Are you saying that it's OK to make extra unnecessary work for you? I'm sure your clients must love that... ;-)

Well I like to look at this one a bit deeper. If the data gathering was accomplished with a SQL SELECT described before in this thread, you'll not experience a smooth transition to Client server:

Select a.*,b.*;
from patient a, center b;
into temp_curs;
where a.pat_id==b.pat_id

If this one is unchanged when you move to a client/server solution you'll have to have two remote views for the patient and center tables. This will not be a optimal client server solution and can in fact be very slow.

a Better approach might be to create a parameterized remote view which holds the same SQL statement. But here you've got to change the reporting code.

Anotherone might be to pass trough the statement to the backend. Now you've got to embed the where values in a string and sent it to the back-end which also reqiures changes in the reporting code.

Of course you can also use a stored procedure to provide the same result.

Depending on the situation you may not have to give up the xBase code at all. If the backend replicates data (for Decision support and OLAP purposes) to the VFP engine you can still work with the original tables. Only difference is that the tables are now maintained by the SQL server rather than the native VFP way.

AS for changing the reports themselfs. I don't think the clients have any idea of how applications can be managed best, (even we don't), so they can't argue about the work that has to be done. I don't think the client would object when I tell him that I would need a hour or so to check every report and remove the alias prefixes of the objects within it, if i've already spend about several hours or day's to change the data gathering methods. As i said before, this is peanuts.

For the record: In most cases I DO use SQL select for gathering data for reporting, In some cases I don't. In other cases I do combine the two (Issueing a SQL select and the set one ore more relations to other tables) depending on the situation. To me the approaches are certianly not mutual exclusive, there are areas where the xBase approach might be better, in other cases the SQL is preferred, and in some I use both (if many tables are involver and I want to avoid many joins).

As Erik Moore has said before: 'I don't buy the easy migration stories'. IMO Migration to a backend is always a good oppportunaty to extend, modernize and rethink the current application. Often new requirements of the client are the main reasons for the move to a C/S environment.

Just my opinion,

Walter,