In Chapter 9, you learned about the options available in designing a client/server application. In this chapter, you’ll learn how to plan development so as to make the deployment as easy as possible, the options for deploying, and the management of changing theapplication, whether changing the server side, the client side or both.
Planning for distribution and modification is no less important than any other aspect of the development process. You have to provide your users with the ability to install your finished project anywhere they choose, and you must provide a usable mechanism for the distribution of all parts of the application. Then you have to make sure that you have plans in place to handle changes to any or all parts of the product. Finally, during this process you must also devise a method of version control, which encompasses not only the code but also the server side of things. So planning for change is clearly a much bigger job in client/server than in
In this chapter we will look at the planning stages of development, and then examine the various ways of deploying the client side of the application. We’ll explore the actual distribution of a database design for the server side, and wrap up with a discussion of updates andversion control.
Client/server development
What creates the challenge in planning for distribution and change is that you are working with a client/server application. This may sound simple, but it means that one part of the application resides on the client and the other part resides on the server. (Just think what happenswhen you start designing n-tier applications, with three or more parts!)
Again, this might seem obvious, but there are a lot of issues that can make the development process a true headache if the obvious is overlooked. Among other things, if you develop the entire application on one computer, remember that eventually the parts will be separated—no part of your code should assume anything regarding locations. In the following sections,
we’ll examine the challenges of planning for relocation in both Visual FoxPro and Microsoft
SQL Server.
Development environment
Before beginning the development process, it’s a good idea to examine the environment in which the development will be done. Everyone who is a part of the development process will be working on his or her own computer, so it’s important that the code and the database be shared in some fashion during this time. For this reason, it is important to have some kind of source control software. Even if you are the only developer involved, source control software can be a wise investment if it also supports version control.
You should also never make the mistake of assuming that the locations being used for development will remain the same or even have the same relationship once the application is set up for production.
SQL Server and Visual FoxPro
Visual FoxPro acts as if it is a single-user system. Although files, such as tables, classes, and program code, can be shared through rights granted in the operating system, the actual software runs in the memory space of the workstation. This issue by itself is always a problem, whether or not you are developing a client/server application. Since various parts of the client side can be edited at the same time, it is imperative that you use some sort of source control. Source control software, such as Microsoft Visual SourceSafe (VSS), can help maintain controlover the various parts of the development process. VSS works by controlling the various files, only allowing people to check out and edit the components if they have the correct rights, and then locking the files so that no one else can edit them. (There is a feature that allowsmultiple users to edit the same file at the same time, but this is generally not recommended.)
SQL Server runs on a server, so although development can be done from any workstation, all of the changes are right there on the server. Everything is shared, as long as users have the correct permissions within SQL Server. The issue is that all work done on the server, suchas creating tables, views, stored procedures and triggers, is stored right there in the database and its files. There is no direct way to maintain source control over what’s inside a SQL database, but you can maintain source control over files that are not in the database. However, youcan create script files by using SQL Server’s Generate Script Files menu option, from within the Enterprise Manager. This way, whatever is done can be placed under source control. The difference is that a developer could still edit the actual objects in the database without checking the script out first. This means that it is up to the development staff to devise a workable plan for implementing source and version control.
Programming for deployment
It’s important to be aware of the repercussions associated with writing programs that hard-code computer names for the production systems, as they tend to be different from the development systems—not only the computer names, but also the database names can be different.The trap here is that the server name must be known in order for the client application to make a connection. Although it is remotely possible that the production and development systems will have the same name, it’s highly unlikely. This will not always be an issue, and in some cases it may only be something to worry about during installation, but the client-side program should derive the server name from somewhere so that it is not compiled into the code.
This situation presents various levels of difficulty. In the simplest of client/server applications, there is only one server being used and no duplicate databases. In this case, the only thing to program for is the actual connection information. The connection is how the client application establishes which target server to use. This connection can take many forms in today’s modern applications. First, you can use Visual FoxPro’s Connection object that is
saved in a VFP database container. Remote views in a database container can easily take advantage of a Connection object, making them ideal for quick view design. However, Connection objects and remote views can also use predefined ODBC Data Source Names
(DSNs). Furthermore, you can use either Connection objects or DSNs when using the
SQLConnect() VFP function.
The problem with using ODBC DSNs is that they are defined on the computer that is doing the connecting. There are three types of ODBC DSNs: user, system and file. Both user and system DSNs reside on the client computer itself, and even though a file DSN can be relocated to other computers, the server name is still definitely a part of it. This means that the DSN used during development has to be reset at installation in order to point to the production server.
If you use a file DSN, then you can modify it at installation with the server name. That’s because a file DSN is a text file with one line that reads “SERVER=<name of server>.” By using the low-level file I/O functions in Visual FoxPro or the Windows Scripting Host object library, you can create or duplicate a file DSN during the installation process. There are other issues that might have to be addressed in a file DSN; these are covered in the next section. However, the biggest problem in using file DSNs is that, by default, Visual FoxPro does not see them in the database container tools.
Another issue to consider in the development process is the aforementioned possibility that the database might have a different name. This is also addressed by using a file DSN or SQL pass through functions. But it’s not always that simple. There are applications where thereare multiple identical databases—that is, they have the exact same set of tables and stored procedures and everything else. This type of application is used in cases where a business
might have to handle the exact same type of data for many clients, such as accountants.
You can avoid using DSNs by instead providing a complete connect string. To create remote views that use DSN-less connections, you must create a Connection object in a Visual FoxPro database container, and then provide the connect string in the properties of the object.With SQL pass through, you can specify a connect string with the SQLStringConnect() function, allowing you to avoid the need for a VFP DBC. Of course, all of your server communication would then have to occur through SQL pass through.
Hopefully, you now appreciate the necessity of avoiding hard-coded references to servers and databases, and see the wisdom in devising alternatives for creating such references. One of the simplest techniques is to make the whole connection process data-driven. Forexample, you could create and use a local table that stores server and/or database names. When the application is launched, the table values are read and stored in variable names, or properties, that are used throughout the code. During installation, a procedure captures the servername,
the database names and their locations, and stores them in the local table. The fact that this table may be duplicated is not a problem, as long as it is accessible to the user who did the installation, or other users if the app is run from a network.
Deployment models
Once you’ve written and tested the application, how do you deliver it? Before exploring the various options available for distributing the server side of the application, let’s look at the various methods of sending the applications out to the users.
Traditional
In the old days—before Windows, before components, before multi-tier and, most of all, before the Internet—applications were deployed very simply: You copied them. You’d develop the program using whatever development platform you wrote in, copy the files to a floppy diskand
send or carry it to the target system, and then copy them from the floppy to the user’s hard disk or network drive.
The only problem was that in order for this to work, the program had to be compiled into a stand-alone executable. With products like FoxPro, you had to make sure that the user had a copy of the same package that was used for programming. It did get simpler, in a way, onceyou could distribute a run-time version of your development package, with no extra cost! But whether it was a run-time or a development version of the language, you started down a
slippery slope. Soon, with Visual FoxPro, it isn’t enough just to install the code and a package; other programs are also needed. That requires you to be very careful about matching up the development platform with the users’ platforms.
Components
Once programming no longer involved just one development product, it became necessary to find a way to break the application apart, and a way to make sure all the parts would find their way into the delivered application.
Components came to the rescue. Components are just a way to break a program into parts. Each part performs various tasks so that no part needs any particular set of parts (i.e., they have low dependency on each other). Of course, after years of trying to write “reusable”code, Visual FoxPro came along and introduced you to classes, and suddenly, reusable code became the
rule. So in using VFP, you started to break down the parts of an application into components, such as user interface, business rules and data handling.
Having done all that, VFP also was brought into the Microsoft component fold, allowing you to take advantage of third-party components, even components not written with Visual FoxPro. How this all came about is a part of the never-ending saga of finding better ways to write and maintain programs, while making them match up with the users rather than forcing users to match the code.
Microsoft’s answer to components is the Component Object Model (COM). COM works by registering the details of every component that’s installed in your Windows operating system. This is handled through the Windows registry automatically whenever any component software is installed on a computer. Then, when another product needs to use that component, Windows looks up a code known as the class ID (or CLSID) in the registry to determine where the actual software is for that component.
When you create an application, you can take advantage of these components and even create your own. Then, when the project is turned into an application, you must collect all
of the components you’ve used and make sure that they get installed and registered on the target computer.
The advantage of using components is that they can be modified and reinstalled without your having to recompile the entire program. In this way, minor modifications to these parts can be made independent of all other parts. Using the old way, everything was written into one big program, requiring you to redistribute that big program every time a change was made.
Server
The new element in today’s environment is that the server side also has to be deployed. This includes the database design, the seed data for the database, script files that are used with the application, and a plan for importing data from other sources to start the database. Unlike the
client side of the application, there is no automatic way of packaging the parts of the server side. The server can consist of many separate files that have no real connection to each other.
This means that you have to use a technique similar to the old way of doing things. That is, some files may have to be transported (copied) from the development platform to the server’s production platform.
In the next section, we will explore the various challenges of deploying the server, and the different ways of actually accomplishing this.
Distributing databases (creating)
Before you begin to plan for the distribution of new databases, you need to determine whether SQL Server 7.0 is already installed at the production site. After this issue has been determined and handled, the database must be created and initialized at the site. In this section, you will see the challenges of handling installations and database creation.
Existence of SQL Server
As stated earlier, you should not hard-code the server name, because the server name may be different after installation. But there are other issues as well. The big question is whether or not SQL Server already exists on the target server. If it is already there, then you mustdetermine whether it is a full-fledged multi-use server, whether there might be multiple databases for different applications, and the availability of a database administrator.
First installation
If there has never been a SQL Server installation, then you may be responsible for setting it up. That means obtaining the Microsoft SQL Server software and the correct number and type of licenses. Yes, unlike the client side of the application, which in many cases can bedistributed royalty-free, Microsoft SQL Server requires licenses. For information on licensing, see Chapter
3, “Introduction to SQL Server 7.0.”
There are a number of other issues that you must consider when installing the server, such as the character set, the sort order, the Unicode collation sequence, the account to use for the SQLServer service and SQLServerAgent service, and which components need to beinstalled. These are the same sorts of things that you should have encountered when you installed Microsoft SQL Server in the development environment.
The recommended method of handling a new installation for a client system is to use a batch file and an initialization file. The initialization file will contain all the instructions needed by SQL Server’s setup program so that the install can be done unattended. There are several sample initialization files that ship with SQL Server, but if you need to create one of your own, you can launch the setup program with an option that will save your choices into an initialization file. You can even cancel the install at the last step and the file will still be
created. The last step will be to include two extra sections needed for the install process. These are the [SdStartCopy-0] and [SdFinish-0] sections. You can find examples of these sections at the beginning and end of the sample files.
The following command creates the initialization file:
setupsql.exe k=Rc
This will create a file called setup.iss in the \Windows or \WinNT directory. To use the initialization file that was just created, use the following code:
start /wait setupsql.exe –f1 C:\WinNT\setup.iss –SMS –s
The “start /wait” together with the –SMS switch forces the installation to complete without returning to the command prompt until the setup is finished. The –f1 switch must specify the full path and name of the initialization file that you create. The –s switch causes it to run in silent mode and never present any screen to the user. You must include a full path to the setupsql program.
If you are controlling the installation through a batch, then you’ll also need to allow the user to choose the location of the SQL Server software and databases. That choice will be
for both the computer where SQL Server will reside as well as the folders where the program and databases will be placed.
Once the Microsoft SQL Server installation is done, your server-side database can be installed.
Prior existence
If SQL Server is already in place at the location of your client/server application, then the entire process can be as simple as having the user point to the server, and then choosing the location
of your database. The consideration here is whether or not there is already an active SQL Server installation at the target site.
If there is an active server for other databases, then security is an issue. In order for your installation to be successful, the person or job doing the installation must have the rights to create a database, or be a system administrator. If there is already a database administrator at that site, then it’s possible that the installation would have to be in conjunction with that person or department. There are SQL Server facilities where security is maintained very tightly and permissions to act as a system administrator are severely limited. This means that you willhave to coordinate the software installation with the database administration staff.
SQL pass through
With the SQL pass through method, the entire installation can be done entirely from within Visual FoxPro. It can also be data-driven, with all of the components of the database stored in a table, and then the SQL commands can be created dynamically and passed into the server.
The first step in using this method is to establish a connection to the server. There are three ways in which this can be accomplished:
• The SQLConnect() function
• The SQLStringConnect() function
• A remote view, followed by the CURSORGETPROP() function
With the first method, there are two options. You can use a predefined Connection object from a database container, or you can supply the ODBC data source name, followed by a login ID and password. The second method uses a string that contains all of the informationneeded
by the server in order to connect. Both of these connect functions will return a connection handle that will be used in future SQL pass through functions.
The last method first connects via a remote view; then, by querying the resulting cursor’s ConnectHandle property through the CursorGetProp() function, the same result is achieved. Here are samples of these three methods:
hSQL = SQLConnect("MyServer","Installer","password")
hSQL = SQLStringConnect("DSN=MyServer;UserID=Installer;Password=password") USE MyRemoteView
hSQL = CURSORGETPROP("ConnectHandle")
The connection handle is then used in subsequent calls to the server as the first argument in all of the SQL pass through functions. The only function that can be used with data definition language is the SQLExec() function. This function takes two required arguments and one optional argument. The first argument is the handle; the second is the SQL statement to be executed on the server. This statement can be a parameterized query, similar to parameterized views, so that values for the statement can be supplied through other variables. The thirdoptional argument is the alias name for the result set(s) returned from the command, if any. By default the alias used is SQLResult, but you can specify any name.
After adding some tables, you could use the SQLTABLES() function to download the names of the tables and/or views that you’ve created in the database. Your program might do this to check that all of the objects were created as desired.
There are other SQL pass through functions that can also be used to look at columns, start and complete transactions, and set properties for the connection itself. One thing to remember is that the SQLExec() function allows multiple statements to be sent to the server.
The advantage of using SQL pass through is that all of the setup code is done through a routine written in Visual FoxPro. The disadvantage is the same thing. If you’ve built a SQL Server database for development and testing, then you already have the format needed for the installation. In order to create a VFP pass through program, you’ll also have to write a program to break the database down into its component parts and objects.
SQL scripts
SQL scripts allow the entire SQL Server database to be created through text files containing Transact-SQL commands. Using this technique, you will need to have the script files (usually text files with the extension of .SQL) sent to the target system during installation, and then launch them either by loading them into the Query Analyzer tool or through the use of the command utility osql.
The advantage of script files is that they can be generated automatically through a menu option in the Enterprise Manager. This option takes you to a dialog where you choose which objects to script, as well as other options such as scripting the permissions, making sure the appropriate logins are in the script, and ensuring that indexes, triggers and constraints are part of the script as well.
The disadvantage of this option is that it does not automatically script the addition of any data that may have to be in the database before the application begins. This requires additional scripts to run in order for the data to be inserted.
SQL-DMO
SQL Server’s Distributed Management Objects (SQL-DMO) is the framework upon which the Enterprise Manager is built. By using the same object model, you can write Visual FoxPro programs that can do the same things as the graphical user tool that ships with SQL Server. In fact, you could design your own graphical tool for the installation of your application.
As with SQL pass through, SQL-DMO affords you the client-side programming option of installation. SQL-DMO is more specific than pass through. In this method, you instantiate objects to create, set their properties, and then execute the methods that will do the job. The following example creates a new database:
oSQLServer = CREATEOBJECT("SQLDMO.SQLServer")
oSQLServer.Connect("MyServer","sa","")
oDatabase = CREATEOBJECT("SQLDMO.Database") oDataFile = CREATEOBJECT("SQLDMO.DBFile") oLogFile = CREATEOBJECT("SQLDMO.LogFile")
oDatabase.Name = "CSExample"
* Define the primary data file oDataFile.Name = "CSData1"
oDataFile.PhysicalName = "C:\MSSQL7\DATA\CSData1.MDF" oDataFile.PrimaryFile = .T.
oDataFile.FileGrowthType = 0 && growth in MB
oDataFile.FileGrowth = 1 && 1 MB
oDatabase.FileGroups("PRIMARY").DBFiles.Add(oDataFile)
* Define the transaction log file oLogFile.Name = "CSLog1"
oLogFile.PhysicalName = "C:\MSSQL7\DATA\CSLog1.LDF"
oDatabase.TransactionLog.LogFiles.Add(oLogFile)
oSQLServer.Databases.Add(oDatabase)
Within SQL-DMO, there are objects defined for everything in SQL Server, including databases, files, file groups, tables, columns, triggers, stored procedures, views, users and logins. Everything that has to do with administration of a SQL Server database is covered in this object model.
The advantage of using SQL-DMO is that, like SQL pass through, everything can be handled from a Visual FoxPro program. And the control is much tighter and more exact than with pass through. Just as with the other method, the entire setup of the database can be data- driven, with all of the object definitions stored in a VFP table, or database. Another advantage is that SQL-DMO has events that your program could be set up to handle.
The disadvantage of SQL-DMO is that the database used for development and testing has to be broken down into its component parts; this can be handled with a SQL-DMO program. This method also requires extensive knowledge of the SQL-DMO object model. Just remember that once you have written routines to use SQL-DMO, they can be used again and again in future installations as well as for database maintenance.
You might think that since SQL-DMO is designed for administration, data modifications would require another object library, such as ADO. But actually, there are several Execute…
methods available with the Database and SQLServer objects, allowing you to actually pass through any command, even those commands that return results.
Object transfer (DTS)
If the development system is on a network connected to the target system, then this method may be the easiest way to transfer the structures and data. Within Data Transformation Services (DTS), there is a task that transfers objects from one SQL Server 7.0 system to anotherSQL Server 7.0 system. You can create this type of DTS package by using the Import Wizard in the Enterprise Manager.
To start the Import Wizard, right-click on the Data Transformation Services folder and choose All Tasks | Import Data… The first two screens of the wizard prompt you for the server names, database names and login information. When the third screen asks about the type of
data transfer, you should choose “Transfer objects and data between SQL Server 7.0 databases.” The fourth screen is where you set up the object and data transfer. The default options are shown in Figure 1.
Figure 1. The DTS Import Wizard “Select Objects to Transfer” screen.
This screen is where you set up which objects to transfer, whether to create the objects on the destination server, whether to drop any existing objects, and whether to transfer the data. By clearing the check box for Transfer all objects, you can choose the Select Objects…button and decide exactly what goes and what doesn’t. By clearing the Use default options check box, you can select the Options… button to set such things as transferring users, logins, indexes, triggers, keys and permissions.
In many ways, transferring objects is very similar to generating scripts. In fact, note that in the screen shown in Figure 1, there’s also a place to specify where the scripts are stored. That’s because the transfer objects task does the transfer via scripts that are just about thesame as the scripts that would be generated by the SQL scripts option discussed earlier.
The advantage of this method is that the transfer of objects is automated to a high degree, and once the DTS package has been created, it can be run over and over again until everything is set up just the way it should be. The other big advantage of object transfer is that any data already set up before production can also be transferred in the same process.
The disadvantage of this method is that it only works when the source and destination are connected. Another problem is that different techniques will be required when doing server upgrades because the transfers are of whole objects, and this method does not allow formodification of objects—at least, not without losing any existing data.
This method is also attractive if you have data in non-relational sources that will need to be transferred into the client/server system. This is because DTS is designed to pick up data from anywhere through OLE DB, and transform it and copy it to any destination. Since youwould already be using DTS for the object transfer, then it would require just a little more work to incorporate the transfer of the data within the same package. All it would need is the addition of some other tasks to the object transfer package.
Backup/restore
Another method that is also simple and straightforward is to create a backup of your development database and restore it on your production server. If the setups for the development and production systems are identical, then you can use the SQL Server backup. Simply back upthe database to tape, disk or across the network, and then use the SQL Server restore process to put the database into the target system. In order for this to work, both SQL Server installations must have used the same installation options, including character set, sort order andUnicode collation sequence.
Since the files that make up the database must be the same number and size, the relative capacities of both systems must be the same. That is, if you have a 20GB data file when you back up the database, then you’ll have to restore to a 20GB file. You cannot split it into separate files when you do the restore. On the other hand, you can put the files that make up a database in different relative locations when you do the restore.
Probably the most common reason for using this method over others is that the backup files can be transferred easily. The only reason not to use this technique is that your development version of the database may have objects that are only for development and shouldnot be moved to the production system.
sp_Detach_DB and sp_Attach_DB
Yet another way of transferring the files that comprise the database is to use two system stored procedures called sp_Detach_DB and sp_Attach_DB. This method is actually preferable to the backup/restore method in some ways.
By using the system stored procedure sp_Detach_DB, you can remove a database from the server where it is located without dropping the files. Once this is done, you can simply copy the data and log files to the target system and then use the sp_Attach_DB system storedprocedure. In fact, if the source SQL Server is not running, you don’t have to use the sp_Detach_DB procedure. Instead, you can simply copy the files while the server is not running.
The advantage of this method is that the transfer is very simple and straightforward, with just one caveat: The sp_Attach_DB procedure requires the name of the database and the
physical names (locations) of all of the files. There is also a limit of 16 files per database in one command.
There are a couple of disadvantages to this method. First, if you detach the database, then you’ll have to run the sp_Attach_DB stored procedure to reattach the database to the originating server. However, this could also be an advantage, since you’ll be testing your command for the production system. Another disadvantage is that, like the backup/restore method, the installation options for both target and destination must be the same, and you will want to make sure that there are no development objects in the database.
Table 1 summarizes the various installation methods.
Table 1. Summary of installation methods and their respective advantages and disadvantages.
Installation method
Advantages
Disadvantages
SQL pass through
functions
Client-side programming.
Everything is done through T-SQL by
using the SQLExec() function.
All objects must be turned into code.
SQL script files
Can be generated via menu
option in Enterprise Manager.
No data inserts are handled
automatically.
SQL-DMO programs
Client-side programming.
Object model code withproperties, methods and events.
Requires careful coding, covering
all objects.
Normally does not handle data inserts. Tends to perform more slowly than other methods.
DTS Object Transfer
Uses built-in tool.
Can handle database objects and data.
Transfer only works when systemsare
on the same network.
Backup/restore
Uses built-in tool, no coding
necessary.
Source database cannot have any
development objects in it. Installations must be identical.
sp_Detach_DB and
sp_Attach_DB
Uses built-in system stored
procedures.
Source database cannot have any
development objects in it. Installations must be identical.
In choosing a method for installation, you must also consider how you will be handling updates or modifications to the database. The next section covers this topic.
Managing updates
Updates are very difficult to manage, especially in a client/server application. That’s because you might be updating the client-side programming, or the server-side database, or both. This requires you to devise the update strategy before you even begin the installation.
In this section we will look at the various elements of the update process, and conclude with the challenge of coordinating between client and server.
Application changes
On the client side, you have the program or application to consider. The issues here are that no project is ever done, and you have to make sure that the application can handle change easily and that the system for managing change keeps the program consistent. Changes can takethe
form of minor bug fixes, major changes to the way the program works, and upgrades to the system that result in the product being vastly different than it was before.
Managing code changes is not new to client/server, and many of the issues surrounding this task are the same as with other application architectures. The difference with client/server is that a program can be split up into different parts that do not have to be modified at the same time.
Version control
The first step in handling updates is to have source control software that will help you manage the process. It’s also helpful if you can do version control, either in the source control software or in the application itself.
A common technique today is to add a version number to your executables, where the numbers represent major, minor and revision changes. The major number is reserved for big changes in the application, such as new features that were not in the original program. Also, a change in the user interface screens may be regarded as a major modification. Minor numbers are used for changes that are less dramatic but demonstrate some sort of visible change. For example, a new option could have been added to a menu or a new screen incorporated seamlessly into the application. Revision numbers typically represent a new compilation of the code that corrects application bugs.
Figure 2 shows the screen in Visual FoxPro where version numbers can be set. This screen is accessed by choosing the Build button on the Project screen, and then choosing the Version button in the Build dialog. The Auto Increment check box causes the Revision number tobe increased by one with every build. You can only use the Version screen by creating a COM server or Win32 executable.
Figure 2. Version dialog showing where to indicate version numbers.
When you are checking a copy of an existing program and trying to determine the version number, you can use the AGETFILEVERSION() function to build an array of information from this dialog. Element number 11 will have the product version value.
By using version numbers, it’s easy to track down bugs that have already been fixed. First you determine the version of the software that the reporting party is using, and then see whether that bug was fixed in subsequent versions.
The most important aspect of version control is managing the distributed versions. If there are multiple copies of the client code, then every user has to be tracked and updated. You may need to maintain a table of this information to track exactly who has which version. Youmust also have methods in place to make sure that you do not overwrite a newer version with an older update.
Traditional
With a monolithic application, a new version is the entire application. This means that the entire project has to be rebuilt and then distributed in some manner to the customers or users. No matter how small an adjustment was made to the code, you must distribute the entire program file.
In using this method, you will need to create an update program that reads the version information from the target site, so that the version being installed is assured of being
more recent.
Component-based
The big advantage of components is that the entire application does not have to be distributed for every change. Rather, components are separate parts of the whole that have an interface that’s unlikely to change. Here the word interface refers to the way one piece of code “talks”to another piece of code. For example, you might have a form that gathers information from the user and then passes the data on to another piece of code that validates that data. Since the validation routines are not in the form, they can be updated separately from the form itself.The only thing to make sure of is that the names of the methods and properties of the validation component are not changed.
The major disadvantage of component-based applications is that each component will have its own version number. This is where the minor numbers can make a big difference. A minor number change can indicate a change in the interface of a component, so that you could have a system where components always match up as long as the major and minor numbers are the same.
In spite of any versioning problems, components are currently the preferred mechanism for creating applications. In this way, each component of an application can be modified and improved with little impact on other components. In fact, it’s possible for applications to be developed using different software products as long as they are component-enabled.
Database updates
Database changes are a little more difficult than simply modifying code. For one thing, some updates are changes to the database schema (i.e., the structure of tables), which impacts data already in the database. Other changes could involve improving performance by modifying, adding or dropping indexes. New stored procedures could be created in conjunction with added
features of the client-side application. Existing stored procedure code could be modified to handle changes to the schema, or to take advantage of changes that improve performance.
Version control
Version control is much harder to manage on the server side because there are no built-in version numbers in a SQL Server database. In addition to the aforementioned problems with source control, you will also have to manage your own version numbers.
There are fewer options available for updating SQL Server than there are for installation. For example, it’s not possible to back up the development database, or even a sample production database, because the restore process would overwrite any data that the user of the application had added to the database. Transferring objects would only work for new objects,
or non-data-containing objects such as views and stored procedures. And there’s no way to use the sp_Attach_DB system stored procedure without encountering the same problems associated with the backup/restore method.
SQL pass through
Just as with installation, this method allows you to do updates via Visual FoxPro code. SQL Server supports ALTER commands for modifying the schema of tables, so it is a valid approach. The biggest advantage of this method is that the update code can be a COM server orexecutable that would have a version number matching up with the changes to the server. This would be just one way for you to manage the version control of the server side of
the application.
The disadvantage is the same as for installation. You must break down the objects from the database into either data for a control table, or the actual ALTER statements. This also makes the maintenance of the database difficult. Should objects be stored as they were originally created, and then include information about their changes? Or should they be stored as the
result of the changes?
SQL scripts
For changes to a SQL Server database, SQL scripts are probably the best method. That’s because as you make changes to the test database, you can save the changes as scripts. Nearly every tool in the Enterprise Manager that can make schema changes has a “Save change script” button that allows you to save the commands the Enterprise Manager generates. This way, you will be able to know exactly what was done and when. It also helps with source control because source control systems can monitor new files just as easily as old files.
If you are not using the Enterprise Manager, whatever commands you create to modify the database can be saved in script files and then used to update the production systems. The disadvantage that was stated earlier for this method does not apply for updating the schema.So for all practical purposes, this is the preferred method, but it still does not solve all of the version control issues.
SQL-DMO
This method is similar to SQL pass through, but instead of just using Transact-SQL commands, you would use the objects of the management object model to set properties and run methods. The advantages of using this technique are that the code is much more precise than usingthe
SQLExec() function, and that it can also be used for querying the current structure of the database.
Since a VFP program would be used to handle the update, you could do the same thing
as with the pass through option and set versioning information in the update code. You would do this by using COM servers or executable programs and storing the version information for the database in the program. This method would still not solve the problem of creatingversion number information within the database itself.
The disadvantage of this method is that you would have to know exactly what the changes are, and document as well as program them. Otherwise, there would be no native way of knowing exactly what changes are made.
Version control coordination between client and server
Version control has been discussed previously in regard to knowing what version a user has and what bugs occurred in that version. Here we’ll address the issue of matching versions of clients and servers.
This is the most difficult area to manage because a change to one side of the application has no direct impact on the other in terms of version numbers. As an example, suppose you make a change in a table’s schema. This may necessitate either a change in stored procedures that access that table or in client-side components that access that table. If the changes are required in both client and server, then the changes in one are incompatible with earlier versions of the other. But there is no guarantee, given the nature of client/server, that the changes will be applied at the same time. If there are no safeguards, then this could cause a crash of your application or, worse, corruption of the data within the database.
In order to avoid this, you will need to create a versioning mechanism on the database, so that the version can be checked against the version of the client-side code. Your program has
to know, or find, its own version numbers and then match them against the version numbers on the server.
This version control situation can get quite complicated. For example, you might have made updates to the client application that do not affect the server. Or perhaps you’ve made updates to the server that do not impact the client. When a modification requires both to change, it can create a strange situation in which a client version would work with certain server versions, but not with others.
It is imperative that you manage this carefully. Create a table in the database that stores the major, minor and revision numbers, and perhaps even use a fourth value for purposes of coordination. Then your client code would have to query that table and match up the values to the revision values internal to the code. If there is no match, then the application should
end with a message about the upgrades needed, or automatically begin a process that performs the upgrade.
Local lookup data
As mentioned earlier, it may be beneficial to have data stored in local Visual FoxPro tables instead of on the SQL Server. Let’s review why you might use them, and then we’ll offer some ideas about how to ensure that they are up to date.
Why
Sometimes a client/server application has data that rarely changes. Every development project will define “rarely” differently, but this could be data that is changed monthly, yearly, daily, once per session or never. But however you define what constitutes a “rare” change, onceyou’ve made that decision, you can improve the performance of your application by downloading rarely changed data to local tables on the client machine. Once the data is local, then lookups into that data will go much faster, improving overall speed. How much data can behandled in this way depends on the capacity of the client hard disk and the amount of time needed to download the data.
Of course, you will also have to determine when to download the data for periodic refreshes. As stated earlier, it might be done just on the basis of the date, or upon startup of the client application. In any case, the client application must check for the data locally so that if it’snot there, it can be downloaded. The most important thing on a day-to-day basis is to balance the latency factor against the performance factor. That is, how important is it to have the absolute latest information vs. the fastest performing application.
Managing updates
Local lookup tables present a special concern when updating. The biggest issue is when those tables are modified in any fashion. The updating program itself cannot be aware of all the client locations of the lookup tables. Therefore, when you create updates that impact those local
tables, something in your application should be made aware of the change and then download the latest table (which will include all of the changes).
The challenge is that local lookup tables are part of the client side of the application, but changes to the server are where those tables are modified. In order to handle this special situation, updates to locally stored information will need modifications to both sides of the application: the database and the Visual FoxPro code.
Summary
In this chapter, you have learned about the special challenges of installing and updating a client/server application. Along with the challenges, you have seen several ways of handling these processes. You have also witnessed the special planning that’s required to ensure a successful client/server setup.
You should now understand why it is so important to use some sort of version control, so that when updates are performed, you’ll know exactly how the pieces of the overall puzzle are put together. And that’s just what this is—a kind of jigsaw puzzle, where the individualpieces have to be cut just right to fit. The ever-present problem is that the shapes of the pieces keep changing, making the puzzle that much tougher to solve.
Posts
No comments:
Post a Comment