>That is correct. One of the reasons we are moving away from Access is to make it easier for our customers to add-on their own reports or modify some of the special reports (such as invoices in Accounts Receivable). These changes are typically done with the help of a reseller but presently it means they get our source code, change the one report they need to change, and then create a new MDE for A/R and we proceed to stomp all over their changes with our next upgrade. I am planning on making it easier for reseller changes and our upgrades to co-exist with this planned change away from Access.
>
>We are planning on using Crystal Reports as an option for our resellers but was hoping to use the FoxPro report writer for all of our standard reports.
>
>>
...

I don't see any major problems with using Foxpro's report writer for simple standard and non-customizable reports. Even for your resellers the report writer can work as long as you distribute and make a way to call these individual 'report files' from your code and not make them 'internal' so that they have to build a new executable,etc. They can just make new report files and list those files in a table that the program reads at runtime. Of course this doesn't help the customer very much but the resellers will like that because they get recurring revenue for customizing reports. Still, there are simply some thing that the Foxpro report writer just can't do but you know that already. :)

>
>This problem concerns me the most of any that I have heard up to this point in time. I really don't have any control over what my customers decide to use for hardware (quite often they have purchased the hardware before we ever get to talk to them). We seem to have a fair amount of difficulty with this type of problems with Access also so it may be just more of the same for us. I hope to get some input on this question from Microsoft since I have e-mailed the FoxPro product manager.
>
...
As long as you have a well-informed reseller base then you shouldn't have too many problems with hardware. It's not like you're trying to compete against what I would consider actual 'mass-market' accounting packages. I've noticed in my work that I have more hardware-based problems with Foxpro than with other development environments. I've just made it a policy to think twice about supporting my applications on hardware I can't reasonably control. It would be great if you'd let us know what Microsoft tells you.


>I appreciate your input here. It does, however, seem like SBT has been quite successful with FoxPro.
>
>Jon I.

Yes they have. And I wish you luck if you decide to use Foxpro like they do.