A basic checklist for deploying Visual FoxPro apps


We have been developing applications for years and learned the hard way what you need to do beforehand when preparing to deploy a Visual FoxPro application into the production environment. Here is a list of things to consider before you implement a new application or deploy an update to an existing application.

VFP Source Code issues

One of the first things you should do before deploying a VFP application is run a process on all the reports distributed in the application or separate from the application that eliminates all content from the TAG and TAG2 columns , and some of the content of the EXPR column, in the first record in the report metadata files (FRX). Running this process eliminates most of the printer problems we have seen in production environments. (See Figure 3 .) In case you are not familiar with this issue, Visual FoxPro stores specific printer information in these fields. If the printer information stored in these fields is from a different printer than what your customers have in the production environment, you could see strange printing behavior with the application reports. More details on how to solve this problem can be found on all the message support forums and in Hentzenwerke ‚ s 1001 Things You Wanted to Know About Visual FoxPro (KiloFox) in the section titled ‚“How to remove the printer information from VFP reports. ‚½


Figure 3. Cleaning out the report metadata before moving the application reports into production is a lesson most developers learn the hard way.

Make sure you have a solid understanding of all the various SET commands and your main program configures them specifically . Leaving SET commands to initialize the Visual FoxPro environment with their default values might not be the same as what you set them in the development environment. For instance, many developers SET EXCLUSIVE ON in development to MODIFY STRUCTURE , REINDEX tables, and ZAP test data. Your production application, if it is a multi- user application, will need SET EXCLUSIVE OFF in the main program.

Include a READ EVENTS to introduce a wait state in the application. It is very common for first time deployments to suddenly realize the application starts, briefly displays the Visual FoxPro frame, and quickly shuts down. The READ EVENTS command is designed to introduce the necessary wait state. Make sure the application has a way to call the CLEAR EVENTS command when the user decides they want to exit from the application. This command removes the wait state.

Visual FoxPro is well known for its use of relative pathing with respect to data and the form data environment. This means the relative path is stored in the cursor ‚ s Database property (see Figure 4 ). When the cursor is instantiated and looks for the table in the database, the database needs to be available in the same relative path from the application as it was on the development machine. In our experience customers like to establish the data on a different drive from the application and developers typically keep the data in a folder under the application folder. Code can be included in the data environment BeforeOpenTables method that changes the Database property before the tables are opened; otherwise , the database needs to be located in the same relative path on the user ‚ s machine as it is on the developer ‚ s machine.


Figure 4. Visual FoxPro stores relative paths in the Database property of the cursor object. This can create errors in your application if you do not change the property at runtime or locate the database in the same relative folder structure in production as it is on the development machine.

Hardcoded paths are an obvious problem, but we often run into this problem in code we review. The D: drive is not always available on every machine. A mapped drive available in development might not be available on the customer ‚ s network, and it can differ from machine to machine or between customer sites.

When building the final version you are shipping to your customer, make sure to check the Recompile All option so all the source code is compiled. Visual FoxPro only recompiles code that changed since the last successful build. If the previous build recorded a syntax error, that code is not recompiled until the problem source code is changed, recompiled via the COMPILE command, or via the Recompile All setting when doing a build. The Recompile All also compacts the metadata source code files (SCX, VCX, MNX, FRX, LBX), which leads to smaller executables.

Your SET PATH might be different in development than in production. Developers often set the path to all the folders that have source code so they can run the main program and have the rest of the source be available. In the production environment, most of the files might be in the executable, and selected files outside the executable. The folder structure could also be different depending on customer preferences.

Files marked as excluded in the Project Manager need to be shipped with the rest of the executable files. Again, this might be obvious to experienced developers, but less experienced developers might not understand this setting in the project. Standards might differ from project to project, which is one reason some developers forget excluded files when certain projects are deployed.

Test the executable in the same manner as your end users will be using it. This means you need to run the executable or instantiate the COM object with the runtimes . This will save you embarrassing situations like ‚“Feature Not Available ‚½ errors and will make sure source code files accessed via indirection are included in the project during a build.

Customer environment

Always provide the users with a workstation installation that includes all the Visual FoxPro Runtimes and any ActiveX objects used in the application, as well as any utilities necessary for the workstation to support the application. We recommend testing on a Visual FoxPro-free machine because you can easily forget to install a specific ActiveX control that loads with Visual FoxPro, Visual Studio, or some third-party package you license.

Always perform a system test of the application with your screen resolution set to the customer ‚ s stated minimum. This is something you need to know up front before designing the first screen. Avoiding screens that don ‚ t fit on the monitor is easy and rarely tested until the application is deployed. Visual FoxPro is not forgiving with this either, as it will center the form if you have the AutoCenter property set to true. If the form is larger than the user ‚ s screen resolution, the top and bottom of the form will be off the screen and users will not be able to reach the controls hidden other than through the native tab order. The biggest reason for this problem is most developers have very high resolutions and forget this requirement during development.

Application dependencies like Microsoft Office (Word, Excel, and Outlook), the OpenOffice.org Office Suite, Internet Explorer, QuickBooks, Acrobat, Windows Scripting Host, and fax software are very common today. First of all, you need to verify the applications are loaded on the machines accessing the apps. The other concern is the version of the products and the data formats you encounter might be different in production from what you tested in development. This is a big problem with vertical market applications and large organizations, or in organizations transitioning from one version to another, or in some cases, to completely different products that provide the same functionality.

Application specific testing

Perform the ‚“empty test. ‚½ We often develop and test with records already existing in the tables, but these get cleared out and typically we install a fresh and empty database at the customer site for testing with new applications or when we add new tables to an existing application.

The other side of the spectrum includes capacity testing. Load up the tables with data at 120% of expected capacity. This allows developers and customers to see how well the application will perform when large volumes of data are processed . It often catches developers by surprise when the application does not perform well, and the likely cause is the test data they used is a small subset of the data used in the actual production environment.

If you are using a security scheme in your application, make sure to have a user preconfigured with access rights in the application for the initial user to use when they start the application and establish security for the other users.

Backend databases have a different set of concerns as far as setting rights goes (see Figure 5 ). Developers might have an open security system to reduce the headaches during development, and can be surprised when the customer has very tight restrictions based on the database administrator ‚ s recommendations.


Figure 5. Backend databases like SQL Server give database administrators the ability to set security down to the column level for application users. This security can affect your application in a negative manner if it is not accounted for during testing.

Metadata (data about data) should be validated and a current set should be deployed with every new installation. Many developers use the Stonefield Database Toolkit (SDT) metadata to drive the reindex process and update structures in production. Commercial and in-house frameworks that provide data driven aspects of your applications often do this with local tables that are changed on the development machine, which needs to be moved into the customer production environment. We recommend each release (no matter how small) be shipped with a current set of this metadata, just in case a developer updated it and forgot about it.

Registry entries, INI configuration text files, and tables are used to track and retain user and application settings. It may be necessary to create and update these in the production environment.

Network and Operating System issues

Make sure you are using fonts in the application available at the customer site. Do not use special fonts installed with the desktop publishing program you use to create the user guide, because the likelihood of these fonts being present on the customer ‚ s workstation is low. The same goes for browser-based applications, because these applications typically have a broader audience. It is nice that Windows attempts to substitute a font on our behalf , but it could be that the font chosen will not look as good as you want it.

Copying files directly from a CD-ROM on some operating systems (Windows 95/98/NT4/ME/2000) will retain the Read Only attribute. This can be a problem for tables, indexes, memo files, database containers, the FoxUser resource files, and even INI configuration files. Executables, images, and other files you deploy might not have an impact with this attribute. Windows XP does not carry over this attribute by default when files are copied from a CD-ROM.

Setting access rights to the files using the operating system security appropriately will give the users access to the application executables and other files. If these rights are not set correctly, the users who should have access might not, or unauthorized users might gain access to the application and data even though they should not be able to do this. Developers typically have administrative authority on the development machine and do not test the application with a user ID with less than god-like authority. This is more of a problem with customers who are running Windows NT4/2000/XP.

Security can be an issue with the installation of the application as well. Companies running Windows NT4/2000/XP do not typically give end users administrative rights to their machines. This can be a problem for the installation package as it tries to write files to secure directories such as the Windows System folder and even the application folder. Make sure to work with the onsite support staff (if there is one) in advance to schedule the installation. If you are the support staff, make sure to know the administrator password when you go to make the installation. This applies to both installing to the server and the local workstation.

WinAPI calls and integration with Windows services need to be tested on each platform running in the customer environment. Not all WinAPI calls work on all Windows versions. It may be more practical to do this in the customer environment, but we recommend accomplishing this before the final user acceptance testing begins. We have separate test machines in our office just for this purpose and use Symantec ‚ s Ghost and PowerQuest ‚ s Drive Image to establish images of the different operating systems so we can perform platform testing. Another avenue to pursue in this regard is VMware ‚ s VMware Workstation. This product allows you to establish one or more virtual machines that can be loaded for testing the various platforms you will be deploying.

Verify the existence of operating system components like ODBC drivers, Internet Explorer, the XML parser, ActiveX Data Objects (ADO), the correct version of the .NET Framework, Microsoft SQL Desktop Engine (MSDE), and Collaboration Data Objects (CDO) so the applications do not fail when they interact with this technology. Microsoft has downloads for all of these technologies so you can have them ready in case they are needed. Making sure the correct version is loaded on the machine can be a time consuming task.




Deploying Visual FoxPro Solutions
Deploying Visual FoxPro Solutions
ISBN: 1930919328
EAN: 2147483647
Year: 2004
Pages: 232

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net