>>>>Is it really "browser-based", running IN a LAN then?
>>>
>>>Yes. Browser based. Server is outside on the internet.
>>
>>I know this is probably a topic for entire new thread but since Jim already started asking, if you don't mind, I would like to ask something. How does your app access the data? And what is the app written in?
>
>Not at all. Our application is 3 tier as follows
>
>UI:
>- browser based
>- ASP.NET pages written in C#
>- calls the middle tier business classes to get ado.net datasets
>
>Middle Tier:
>- business clasess written in C#
>- actually 2 levels, first is abstract classes which call a set of generic data classes that get and store data
>
>Database:
>- SQL Server 2005
>
>Reporting:
>- a VFP executable that runs 24/7 on the server
>- the .NET app puts report requests (XML strings) into a table that the VFP app picks up and executes-
>- when the report is complete, the path and the name of the report is stored back in the table, which the .NET app then picks up
>- we use this because so far we haven't seen a need to spend the time to convert to anything else. It is fast.
>
>All of these compnents live on the same server which therefore acts as a web, application and database server. One catch of using VFP as a report server, is that there is no way to throttle what percent of the CPU it can use. If a report takes a long time, in particular if a single SQL statement takes a long time this can take all of the resources that the CPU has and make your application appear to freeze. If use use SQL Server as your report generator you can throttle how much CPU it will use. I get around this by using a fast dual CPU server. VFP can only hog one processor at a time so the server never gets overwhelmed.
>
>We didn't move to this overnight, it was a migration. We had a Windows app that was pure VFP, but I was strict in using business classes to access the data so this made the migration easier.
>
>First Phase of Migration:
>- rewrite biz classes to pass XML strings that contain the data, instead of putting the data into a cursor
>- recompile VFP biz classes into COM components
>- since the biz classes were mature, we knew that part of the app was very stable and would require very little debugging
>- write ASP.NET pages that then called the COM components
>- reports were already in one business class, so I split this off into its own EXE which then ran on the server
>- change the reports from showing the VFP reports preview screens, to (in general) produce PDF files of the report. This was great because the reports had to change very little. Once again less debugging.
>- because of the reuse of the report classes and business classes we were able to concentrate on learning ASP.NET and debugging problems with that.
>- we mimiced the look and feel of the Windows screens so that I didn't have to do any retraining on the app.
>
>Voila! We basically had the same application code (stable) but a new front end. We then let the application stabilize for a few months and did changes that had backed up during 6-8 months of converting to a web front end.
>
>Second Phase:
>- convert the business classes from VFP COM components to C# business classes
>- this was done for a couple of reasons: firstly we experienced some odd crashes of the IIS worker process every one in a while. Secondly I wanted to learn more C#. Thirdly we realized that C# class accessing a VFP table through OLEDB was about as fast as using a COM component to do that. That was very unexpected.
>- in this phase, because the design was pretty clean we were able to for the most part convert 1 class at a time, then wait for it to stabilized then do another one.
>- because of converting 1 class at a time I never had to sell the boss on this conversion. I would just do it between every 2nd enhancement that I was already doing.
>- this stabilized our app immensely
>
>We then let the app stabilize for a few months while I did no programming things. Computer training actually.
>
>Third Phase:
>- convert the database from VFP tables to SQL Server 2005
>- we did this mainly because it was getting harder to get ISPs and IT dept to support VFP tables for backups
>- also I wanted to finally learn some SQL Server
>- for this phase we actually shut down enhancements for 3 months while we converted the database
>- SQL Server has an import wizard that will create the tables and import your data for you
>- the work was then changing the data classes to pull from SQL server instead of VFP, not a heck of a lot of difference
>- the biggest chore was the difference between VFP and SQL data types and the differece between VFP and SQL Server SQL syntax
>
>This is where we are at today. I can see moving away from VFP as the report server, but this will probably we a slow migration as new reports are needed.

Evan,

I can't thank you enough for the most detailed description of your project. If I ever get the time and a good knowledge of C# this would be the process I would follow. Meantime, I will print out your message for more study and a guide.

Again, thank you.