Dawa,
>Now, compared to VFP reporting system, how easy is it to create a report in Crystal Report? Or are they just oranges and apples?<I haven't used Crystal, so I can't say. But I see that Craig has already answered. I was going to suggest that either he or Kevin Goff would be better people to answer this.
>In other words, my data access and business logic will reside on the server side called by web services, the remote client will simply talk to the web service interface, is that right? <Correct. Although we've found that, in addition to server-side business logic, we also need some client-side business logic. No problem, just separate DLLs.
>In this way of communicating with the database through web services, could there be any performance issues if I were to retrieve bunch of records for reporting purpose?<You have to retrieve the data from the server some way, so from that standpoint, I don't think Web Services adds much in the way of overhead. Some people will prefer remoting, but since our app isn't designed that way, I've got no experience with remoting. We prefer Web Services.
~~Bonnie
>Bonnie,
>
>Thank you so much for the thorough explaination!
>
>>Do you currently have a VFP app with reports that you want to re-use?
>No. This is a brand new project.
>
>>Starting out with those reports and slowly converting them to Crystal or whatever might get your app out the door quicker. A problem I see with doing it the way you've described it, however, is that you'll have two EXEs ... one for your .NET UI and another for your VFP reporting. Not typically what users would expect to have to do (launch two apps). The only way to get around that, is to call your VFP reporting from your .NET UI as a COM object, and that is not very smooth either!!! All things being equal, I'd opt for reporting through .NET rather than a separate VFP app.
>
>Very good point about the two exes.
>Now, compared to VFP reporting system, how easy is it to create a report in Crystal Report? Or are they just oranges and apples?
>
>>Your architecture looks good, although you might want to think about using Web Services to communicate with your server-side processes.
>
>In other words, my data access and business logic will reside on the server side called by web services, the remote client will simply talk to the web service interface, is that right? This way, I actually don't need to worry about the connection strings for the remote clients.
>
>In this way of communicating with the database through web services, could there be any performance issues if I were to retrieve bunch of records for reporting purpose?
