Software Strategies

When creating reports in Visual FoxPro, it’s important to watch when the printer environment is saved on reports. If you create or modify reports in the client’s office, saving the printer environment should produce the desired outcome on the printed report. Generally VFP programmers don’t always have the same printer that their client do. We go about creating and modifying reports without a concern for the printer environment. We test the printed report on our printers and they produce what the client asked for. Then the report gets updated to the client’s version of the program and it doesn’t work. This happened to me last week.

I modified a report and tested it on my computer and it produced the result. Uploaded it to the client site and a part was missing. I tried it again with the same data and the report printed as requested. After further digging, Mike, our senior programmer, found the problem. In the report properties of the particular report, the Printer Environment had been checked. Mike made a rule for our development efforts – make sure that the Printer Environemt on any report is not checked. Inadvertently or accidentally, I broke the rule. So I unchecked the box, recompiled and it worked correctly on the client site. Another happy client.

Our client asked for a change to an order entry screen in one of our Visual FoxPro applications.  Our senior programmer Mike, accidentally left off the table prefix for one of the fields in a SQL SELECT statement. The net result was that the work tickets printed from the final SQL cursor, sometimes printed customer information and some times didn’t.  After some digging, I found that 2 of the tables in the SQL SELECT statement had the same field name.  The SQL SELECT got confused and sometimes returned the customer information and sometimes didn’t on the printed work ticket. I added the table name prefix to the field and did some testing.

Sure enough, the work tickets that didn’t print the customer information now had the relevant information printed in the proper spot. Our client was happy with the result.

This morning, Mike, our senior program developer, and I got around to discussing how I could use the base classes and generic tools we have developed over the years to develop a simple VFP application. We want to manage the data for a mailing and the responses in our latest marketing campaign.

Mike suggested that he could come up with a generic VFP project with all of these tools, screens and class libraries we’ve developed over the years. This would allow me to get the marketing campaign system up and running quicker. It would also serve as a template for new VFP projects we hope to get as a result of the campaign. More later on how this helps.

One of our clients asked us to update an application we wrote originally 20 plus years ago in Basic in the Microsoft Basic Professional Development System. Over the years, we upgraded the application to Visual FoxPro (VFP) 3.0 and VFP 5.0. Since we upgraded to VFP 9.0, the main screen they use to create packing slips and invoices slowed to a crawl compared to the previous VFP 5.0 version. About the same time as the VFP 9.0 upgrade, the client got a new server and upgraded their physical network, cables and hardware.

My first thought was to point to the network upgrade as the reason for the slow down. My associate Francis, a network troubleshooting expert, and I did some network analysis last week. There was a mixture of 100 Megabit and Gigabit network cards. We found that, while there were some issues with the client network, our focus now shifted to the VFP 9.0 application.

Mike, our VFP programmer, now thinks that what was a valid way of creating the screen in VFP 5.0, no longer works in VFP 9.0. So he is currently reworking the code to create the screen. More to come on what he finds.