Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 1
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Internet Applications
`with
`Visual FoxPro® 6.0
`
`Rick Strahl
`
`Hentzenwerke Publishing
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 2
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Published by:
`Hentzenwerke Publishing
`980 East Circle Drive
`Whitefish Bay WI 53217 USA
`
`Hentzenwerke Publishing books are available through booksellers and directly from the
`publisher. Contact Hentzenwerke Publishing at:
`414.332.9876
`414.332.9463 (fax)
`www.hentzenwerke.com
`books@hentzenwerke.com
`
`Internet Applications with Visual FoxPro 6.0
`By Rick Strahl
`Technical Editor: Gary DeWitt
`Copy Editor: Jeanna Randell
`
`Copyright © 1999 by Rick Strahl
`
`All other products and services identified throughout this book are trademarks or registered
`trademarks of their respective companies. They are used throughout this book in editorial
`fashion only and for the benefit of such companies. No such uses, or the use of any trade
`name, is intended to convey endorsement or other affiliation with this book.
`
`All rights reserved. No part of this book, or the ebook files available by download from
`Hentzenwerke Publishing, may be reproduced or transmitted in any form or by any means,
`electronic, mechanical photocopying, recording, or otherwise, without the prior written
`permission of the publisher, except that program listings and sample code files may be
`entered, stored and executed in a computer system.
`
`The information and material contained in this book are provided “as is,” without warranty of
`any kind, express or implied, including without limitation any warranty concerning the
`accuracy, adequacy, or completeness of such information or material or the results to be
`obtained from using such information or material. Neither Hentzenwerke Publishing nor the
`authors or editors shall be responsible for any claims attributable to errors, omissions, or other
`inaccuracies in the information or material contained in this book. In no event shall
`Hentzenwerke Publishing or the authors or editors be liable for direct, indirect, special,
`incidental, or consequential damages arising out of the use of such information or material.
`
`ISBN: 0-96550-939-7
`
`Manufactured in the United States of America.
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 3
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`I want to dedicate this book to the Microsoft Visual FoxPro team for all their efforts in
`building and maintaining such a powerful development tool. Even in the face of adversity, this
`product continues to kick butt, allowing developers like myself to build amazing applications
`with ease without sacrificing power. I, like many of you, I suspect, have benefited tremendously
`from the power of this product, and I want to thank the team for continuing to pour their
`creative resources into this tool. Thanks, guys (and gals)!
`
`And don't ever let a Dilbert-head tell you that it can't be done with the Fox!!!
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 4
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 5
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`v
`
`Table of Contents
`
`Acknowledgements
`
`Foreword
`
`SECTION 1—Internet Technologies
`
`Chapter 1: Introduction
`Who should read this book
`How this book works
`What we'll cover
`What you need to work through the book
`What you should know about me
`Is the Web in your future?
`Commercial Internet development is exploding
`The move to develop the active Web
`Why build a Web application?
`Advantages of building Web applications
`Distribute widely, administer centrally
`Universal client interface
`The application development platform of the future
`Limitations to building Web applications
`Configuration issues
`Interface limitations of HTML
`Server-based programming model
`Another state of mind
`Take a load off
`Security is not optional
`
`Chapter 2: Internet Application Technologies
`Open standards open doors to the world
`Of clients and servers
`Servers
`Clients
`Clients on a diet
`HTTP makes clients and servers go 'round
`From Web browser to Web server
`A closer look at the server side
`ISAPI, the high-performance extension interface
`Calling all Visual FoxPro servers
`
`xiii
`
`xv
`
`1
`
`3
`3
`3
`4
`5
`6
`6
`6
`7
`8
`8
`8
`9
`10
`11
`11
`12
`14
`14
`14
`14
`
`15
`15
`16
`16
`20
`21
`23
`24
`27
`28
`28
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 6
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`vi
`
`Microsoft's Component Object Model—
` The glue tying Windows to the Web
`COM and Visual FoxPro
`What else do you need to know?
`
`Chapter 3: Setting Up
`Windows NT—Platform of choice for Web applications
`Internet Information Server
`Configuration of the site
`SSL and secure certificates
`Active Server application options
`Explore the dialogs
`IIS admin objects—do it programmatically
`Starting out
`
`SECTION 2—Server-Side Development
`
`CHAPTER 4: Active Server Pages
`Scripting people in a component world
`How it works
`Scripting for the masses
`Objects galore
`All input comes from the Request object
`All coded output goes through the Response object
`System services through the Server object
`Keeping state with Session and Application objects
`Getting down to business—Simple data access with ASP and ADO
`Creating an ODBC data source
`Working with the demo code
`Creating the ASP document
`Error handling with ASP and ADO
`Displaying the logging results
`Looping through the recordset
`Other ways to handle ADO
`A TasTrade invoice viewer application
`Watching out for unnecessary data display
`Complex forms and data access
`How the form works
`A few reservations about VFP and ADO
`Scripting as an application environment?
`Taking advantage of COM with Active Server Pages
`Calling all VFP servers
`
`29
`30
`31
`
`33
`34
`34
`37
`39
`40
`41
`41
`42
`
`43
`
`45
`45
`46
`48
`50
`51
`53
`54
`55
`58
`59
`59
`60
`62
`62
`65
`66
`66
`67
`69
`69
`74
`75
`75
`76
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 7
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Beware of errant paths!
`Understanding server security
`Using VFP to generate HTML
`Getting around slow HTML tables
`Using ASP objects with your VFP COM server
`The IScriptingContext interface
`Objects from Visual FoxPro
`Example—an object-based customer browser
`Sharing data with ASP—passing ADO objects
`An objective warning
`Understanding ASP/COM scalability
`What is Apartment Model Threading and why should you care?
`Summing up
`ASP pros
`ASP cons
`ASP resources
`
`CHAPTER 5: FoxISAPI
`What is FoxISAPI?
`How it works
`Build your application code with Visual FoxPro
`Building the COM server
`Server configuration
`Copy Foxisapi.dll into a Web script directory
`Run DCOMCNFG to configure your server
`Unloading and managing servers
`COM server instancing
`In-process COM objects
`Out-of-process COM objects
`Building FoxISAPI requests
`Returning HTTP output
`Content types
`HTTP directives
`Show me the data!
`Decoding form variables
`Retrieving ServerVariables from the INI file
`The next step—a basic framework
`Why do you need a framework?
`The wwFoxISAPI framework
`wwFoxISAPI
`wwRequest
`wwResponse
`Centralizing the FoxISAPI entry point
`Error handling
`
`vii
`
`82
`83
`86
`89
`89
`91
`92
`93
`96
`99
`100
`100
`104
`104
`105
`105
`
`107
`107
`108
`110
`111
`113
`114
`115
`118
`119
`119
`120
`121
`124
`125
`125
`128
`130
`134
`137
`138
`138
`139
`139
`140
`144
`148
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 8
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`viii
`
`Eliminating those long URLs
`Scripting and Templates
`Implementing a scripting engine with Active Server Syntax
`Templates with MergeText
`Scripting—more power and more work
`Hooking it in...
`An example application
`Other cool things you can do
`Queries against SQL Server
`Creating Adobe Acrobat documents from VFP reports
`Sending data over HTTP
`Rendering Visual FoxPro forms
`Multiple instances via the pool manager
`FoxISAPI debug mode
`Summary
`FoxISAPI pros
`FoxISAPI cons
`
`SECTION 3—Client-Side Development
`
`Chapter 6: Internet Enabling Your VFP Applications
`The easy way to the Internet
`The Shell API
`What about Visual FoxPro's Hyperlink object?
`The Internet protocols of wwIPStuff
`Sending SMTP Internet e-mail
`FTP transfers
`Using the Internet Explorer Shell COM interface
`Capturing IE COM events
`The WebBrowser ActiveX control
`It's not just for Web content
`The Internet Explorer document model
`A Web Browser example
`Editing HTML
`HTML markup formatting problems
`Using the DHTML Edit Control
`Summary
`
`Chapter 7: Building Distributed Applications over HTTP
`Hyper thinking
`How can you use HTTP in your applications?
`WinInet with Visual FoxPro
`Doing data over HTTP
`
`150
`151
`151
`151
`154
`156
`160
`170
`170
`174
`178
`180
`185
`187
`189
`189
`190
`
`191
`
`193
`193
`193
`196
`197
`197
`198
`200
`202
`203
`205
`207
`215
`219
`221
`222
`224
`
`225
`225
`226
`227
`231
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 9
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Real data over HTTP
`Sending data with HTTP POST
`Posting application data
`Hey, Mr. Postman, bring me some data
`Building in even more functionality!
`Putting it all together
`Don't forget about security!
`What about other server tools?
`WinInet issues
`Summary
`Pros
`Cons
`
`Chapter 8: Remote Data Service
`How RDS works
`An example using Internet Explorer
`Table-based data binding with RDS
`Using RDS inside VFP
`Error handling
`Using RDS results in your code
`Problems, problems, problems with RDS data access
`ODBC problems with Visual FoxPro
`RDS problems
`Internet Explorer data binding problems
`Summary
`Accessing objects over HTTP with the RDS.DataSpace control
`How it works
`An example—a generic server object
`Summary
`Beware of security issues!
`Data security
`Object security
`Some workarounds
`DCOM over HTTP
`Summary
`Pros
`Cons
`
`SECTION 4—Enterprise Development
`
`Chapter 9: Visual FoxPro and COM
`COM scalability and Visual FoxPro 6.0
`What is Apartment Model Threading and why should you care?
`
`ix
`
`234
`238
`246
`250
`253
`260
`266
`267
`268
`270
`270
`270
`
`271
`272
`273
`278
`280
`281
`283
`287
`287
`287
`287
`288
`288
`288
`289
`293
`294
`294
`295
`295
`297
`297
`297
`297
`
`299
`
`301
`301
`302
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 10
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`x
`
`Problems with the initial release of VFP 6.0
`An interim release to the rescue
`Using the new multi-threaded runtime
`Multi-threading is not a magic bullet
`Microsoft Transaction Server
`Do you need Microsoft Transaction Server?
`The state of the stateless
`Understanding JITA
`MTS security
`MTS summary
`Pool managers in FoxISAPI/Web Connection
`Pool of single-use EXE servers or in-process DLL servers
`Full administrative control over servers
`Not generic
`Reaching out over the network with DCOM
`Direct instantiation via CREATEOBJECTEX()
`Remote objects without CREATEOBJECTEX()
`Beating the beast: DCOM security
`Security and the IIS client
`Performance and network issues
`DCOM conclusion
`COM summary
`
`304
`304
`305
`306
`307
`308
`309
`314
`315
`316
`317
`317
`318
`319
`319
`320
`320
`321
`323
`324
`324
`325
`
`327
`Chapter 10: Building Large-Scale Web Applications
`327
`Visual FoxPro is ready for the server!
`328
`What is a large-scale application?
`329
`Web site operation
`330
`Performance
`330
`Data optimization
`332
`To SQL or not to SQL
`334
`Code optimization
`336
`Web site optimization
`337
`Web server optimization
`339
`Visual FoxPro and multithreading
`339
`IIS and ISAPI are multithreaded, but VFP is not!
`340
`Understanding CPU load and speed
`342
`Scalability
`342
`Multiple instances of VFP required
`Best scalability achieved with multiple processors on a single box 342
`Use network machines to spread load
`343
`IP Routing/Dispatch Manager
`346
`Data becomes the bottleneck
`348
`Scalability summary
`349
`Site application administration
`349
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 11
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Decisions, decisions—online or offline data
`Remote application administration
`Detailed site and user statistics
`Should you use cookies?
`COM server management
`Security on the Web
`Keep data in an unmapped path
`NT Challenge Response—directory and file security
`Basic Authentication for your applications
`Non-NT custom security
`Do you need secure transactions via SSL?
`Summary
`
`Chapter 11: The Development Process
`Source code integration
`Visual FoxPro developers
`HTML designers
`Consultants and staff
`Separate staging test server
`Integrating HTML and code
`HTML is the front-end interface
`Understand the limitations of HTML
`Data connectivity
`Keep HTML and code separate
`Scripting and templates for data and display logic
`Graphics and site design
`Network administrators
`Site management
`Summary
`
`Chapter 12: Loose Ends
`Data access over TCP/IP
`Accessing VFP data directly over TCP/IP
`Using a SQL server over TCP/IP
`The Great Active Document Swindle
`Treat Active Docs for what they are:
`browser-hosted standalone applications
`Scenarios where Active Documents make sense
`A mini-tour of how Active Docs work
`Getting your application to run as an Active Doc
`Limited menu options
`Active Document Summary
`XML—The new data messaging standard
`What is XML?
`
`xi
`
`350
`351
`351
`352
`353
`354
`354
`355
`355
`357
`357
`358
`
`359
`360
`361
`362
`362
`363
`364
`365
`365
`366
`366
`367
`367
`369
`371
`373
`
`375
`375
`375
`376
`377
`
`378
`378
`379
`380
`383
`383
`383
`384
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 12
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Section 4
`
`Chapter 10: Building Large-Scale Web Applications
`
`327
`
`Chapter 10
`Building Large-Scale
`Web Applications
`
`Web development brings with it special challenges that you might not encounter with
`stand-alone applications. Web applications, especially publicly accessible ones, are
`subject to large numbers of users in unpredictable numbers at any time of day or night.
`Web apps tend to be online 24 hours a day, seven days a week, and often cannot afford
`downtime. The transaction volume on public sites is often unpredictable and in many
`situations grows rapidly from small numbers of users to an onslaught of traffic that can
`be difficult for your network infrastructure, your Web server and your applications to
`handle. In order to build effective applications for this environment, it's important to
`understand what's possible with the tools you are using and how to effectively measure,
`project and finally prepare for increasing load on your servers. Understand up front that
`there is no magic bullet for this process, regardless of which server and development
`platform you end up using (NT vs. Unix, VFP vs. C++, ASP vs. ISAPI, and so on)—they all
`have limitations. Proper integration is the key to smooth Web operation. For example, I've
`seen 100 CPU Unix servers bogging down at much less load than a single dual-processor
`NT box. It all comes down to proper tuning and interoperability of all the pieces in these
`complex applications.
`
`Building an application that can handle large volume requires proper planning and a
`solid understanding of the infrastructure and its possibilities. It's also likely that it will
`require you to work with and understand a number of varying technologies—from server
`hardware and software, to network and administration tools and issues, to software
`development with multiple tools that are right for the job. This job might be divided
`among various groups in the company or it might fall into a single person's (yours?) lap
`to administer. I'll examine the development process and people issues in the next
`chapter.
`
`In this chapter I'll discuss the issues involved with building applications that will
`experience large volumes of transactions on the Internet. There's more to it than simply
`looking at the resources available and the horsepower of the machine on which the
`applications run. Being able to handle large loads requires balancing hardware, software
`and development skills to bring about a balanced and scalable environment that can
`grow as your applications get busier.
`
`Visual FoxPro is ready for the server!
`People often have serious concerns when it comes to using Visual FoxPro on a Web server.
`The main reason seems to stem from the fact that Visual FoxPro is not commonly mentioned
`as a development tool meant for server-side development. However, the fact is that Visual
`FoxPro is an excellent tool for building server-side application components precisely because
`of its extremely flexible data manipulation language (DML), mixed with an easily accessible
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 13
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`328
`
`Internet Applications with Visual FoxPro 6.0
`
`and complete object-oriented implementation and the fastest local, Windows-based database
`engine built into a development product. As you've seen in the server-side and even the client-
`side chapters of this book, there's very little that you cannot accomplish with Visual FoxPro
`code. Although it might not seem obvious, these features—especially performance—are very
`important to building applications that scale well.
`Aside from its language features and performance, VFP is also fully capable of providing
`the basis for building scalable Web and server applications. With version 6.0 and a
`forthcoming Service Pack, which addresses several shortcomings in VFP 6.0's original
`threading model, Visual FoxPro has the ability to scale well in a high-transaction environment.
`You can use many Visual FoxPro servers simultaneously on the same machine, as well as
`scaling servers to other machines over DCOM to extend scalability beyond the limitations of a
`single machine. Coupled with Visual FoxPro's data-access performance, string manipulation,
`and general data-manipulation speed, this makes for a capable tool that can efficiently take
`advantage of whatever system resources (in the form of multiple CPUs or servers) you are
`willing to give it.
`I've been building Visual FoxPro Web applications for a number of years now, and I've
`seen a lot of different implementations, including some very large-scale apps serving hundreds
`of thousands of server hits a day. I've seen applications coming down from large Unix boxes to
`a Visual FoxPro platform, and I've seen Visual FoxPro applications being moved away from
`Windows to Unix. In all of this comparative observation, I've found that Visual FoxPro in
`combination with Windows NT and IIS is one of the best platforms you can use for Web
`development in terms of performance, scalability and development productivity.
`One site in particular that I've been involved with, Surplus Direct, has gone through the
`whole cycle—from a mainframe solution down to NT, and back up to a Unix environment.
`Powered by Visual FoxPro, the site has recently peaked at 750,000 back-end Visual FoxPro
`server hits per day, with peaks of almost 100,000 hits an hour—and with no sign of running
`out of steam. Mind you, these are all database and application logic hits, not just static page
`hits, running on four Windows NT dual-processor boxes. This particular application can scale
`up to any type of load, simply by adding more machines into the server pool, which provides
`nearly limitless scalability (given network bandwidth and database server resources).
`The point is that with proper design and configuration, Visual FoxPro applications can be
`used to serve up any kind of load you might want to throw at them. At the same time, keep in
`mind that building scalable applications requires a difficult process of coordination among the
`operating system, system tools, the network and your application. Regardless of which tools
`you use—from Visual FoxPro to Visual Basic to Visual C++—most of these issues will apply
`because they deal with the infrastructure. In this chapter I'll talk about infrastructure issues as
`well as those specific to Visual FoxPro.
`
`What is a large-scale application?
`When I talk about large-scale Web development, realize that this is a relative term that
`depends on your particular environment and how you approach an application. In general I
`evaluate whether an app is large-scale based on two particular issues:
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 14
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Section 4
`
`Chapter 10: Building Large-Scale Web Applications
`
`329
`
`• Web site operation
`• Development process
`
`If a site is heavily used, it can fall into the large-scale bucket based on its sheer transaction
`volume and load issues. Other applications involve a complex business environment that
`requires the sheer size of the application to be large scale. Some applications have both. In this
`chapter I'll address the Web site operation issues: tuning, measuring, deployment and
`management. In the process, I'll look at various issues of how Visual FoxPro fits into the
`Windows NT and COM architecture and how this affects your development of components
`built with Visual FoxPro. The next chapter deals with the human aspect of the development
`process and interrelationships of its different tasks.
`
`Web site operation
`When judging the "size" of a Web application, many people consider its operational aspects.
`Operational aspects address questions relating to the volume of traffic, the number of hits
`received by certain pages, the number of back-end hits, or the number of records added to the
`database each day. These issues are extremely critical for server-based applications because
`they must be carefully balanced against the capacity of the systems that are running the
`application. If you overload the system you'll lock up the Web site, which can lead to
`disastrous results and loss of money. The operational aspects can be broken down into several
`areas:
`
`• Performance
`Performance is an important aspect of any application. In Web applications, it's even more
`critical because it can affect not only the responsiveness that the user sees but also the
`scalability. The faster a request can be served, the lighter the load on the server and the
`quicker another can be processed.
`
`• Scalability
`Speed is nice, but in Web applications there's the additional factor of many users accessing
`a site at the same time. Scalability deals with utilizing and balancing the load that the
`traffic incurs with the hardware on which it's running. This can be a daunting task,
`especially if your needs go beyond a single server machine.
`
`• Data volume
`Many large-scale Web sites also generate huge data volumes. Dealing with extremely high
`transaction volumes on the data server is a critical issue when designing applications,
`because contention and locking issues are much more likely to occur in Web apps than in
`typical stand-alone business applications. Data volume can be the downfall of the
`application as the SQL back end becomes a bottleneck that cannot be scaled as easily as
`other aspects of the Web application. This involves volume/size scalability as well as data-
`server bandwidth and computing power. Data management also becomes a serious issue
`because it becomes increasingly difficult to store and move the information being
`captured. For example, one site I work with generates log entries for every hit incurred
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 15
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`330
`
`Internet Applications with Visual FoxPro 6.0
`
`and every visitor, along with every order placed. A typical day can generate close to 1
`million new records in the database; storing and moving this data is difficult, especially
`when there's "no good time for maintenance" on the server.
`
`• Site administration issues
`Adding new software or hardware can put serious strain on a busy, live application. Web
`sites are expected to be up 24 hours a day, seven days a week, and any glitch can result in
`a loss of valuable customers. There are also software issues with site administration, such
`as how to update code seamlessly in a distributed environment, how to handle errors and
`logging, and so on.
`
`Performance
`As you might expect, performance is extremely critical in high-transaction environments; it's
`also the most visible aspect that you might be familiar with from standard applications. Any
`application needs to run as fast as it possibly can, but for high-transaction environments it's
`crucial to tune code to make sure it runs at its optimum—slow requests can tie up valuable
`resources that might be needed by the next request in line. In a server environment,
`performance is significantly affected by other system elements, in particular load on the
`server's resources (CPU, disk, and possibly the SQL back end). While tuning your code to run
`as fast as possible is crucial, realize that tuning won't help if you're running the CPUs on your
`server at a maxed-out 90% CPU load. Nevertheless, treat performance as a top priority right
`from the start when you design your applications. Performance bottlenecks typically don't
`show up right away, but rather as applications experience rapid growth or spurts of huge traffic
`loads, which is a common scenario for successful Internet commerce applications.
`When looking at performance, it's important to examine more than just the immediate
`application. Tuning your Fox code is definitely worthwhile, but tuning the operating system
`and maybe even the layout of your Web site can dramatically change the dynamics of how
`much load is incurred on your server.
`
`Data optimization
`Since we're dealing with database applications here, data optimization is the most important
`piece of the puzzle. Database operations tend to be the slowest operations in any Web
`application and also the most resource intensive, so optimizing them can bring the biggest
`benefits. On any given request in my applications, around 80% of the request processing time
`is spent with data access. Data access is, of course, one aspect at which Visual FoxPro excels,
`regardless of whether you're using local data against DBF files or remote connections to SQL
`Servers.
`The following are a few general tips and guidelines to consider. Some are basic common
`sense, but it's a good idea to be reminded and maybe encouraged to review your existing code
`for them:
`
`• Optimize your queries.
`If you're using local data, make sure that all of your queries take full advantage of
`Rushmore. Make sure you set up indexes to match your queries and make sure the queries
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 16
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`Section 4
`
`Chapter 10: Building Large-Scale Web Applications
`
`331
`
`match the indexes exactly. Also, make sure you have tags on DELETED() if you're
`running with SET DELETED ON. Take the time to review performance and SQL
`optimization with VFP's ShowPlan function SYS(3054). If you're using a remote SQL
`Server, use the server's optimization tracing functions to review SQL commands in the
`same fashion. SQL Server 7.0's new Query Analyzer is a great way to optimize queries
`more easily than in previous versions.
`
`• Pull only data you need.
`When using local data it's often easier and more convenient to simply run SELECT *
`queries and perform further filtering in secondary queries. However, pulling that extra data
`takes time and requires server resources, especially if you're using remote SQL Servers.
`Make sure queries bring down only the data you really need!
`
`• Avoid updateable views for queries.
`Updateable views tend to be quite a bit slower than read-only views because VFP needs to
`track the changes you make and then synchronize them with the SQL back end. If you're
`running data queries that use the same views as some update routines, consider creating
`separate views for the query update to localize the overhead of the updateable view to the
`operation that really needs it. For the fastest performance, you can use VFP's SQL
`Passthrough to talk to the remote database directly—although the gains are not that big.
`Personally, I like SQL Passthrough because it offers me extra control and allows for much
`easier error trapping than remote views allow, but it's more work to code.
`
`• VFP data access is much faster than SQL back ends.
`Many Web applications are moved to SQL right from the start, even when they use Visual
`FoxPro code on the back end. Make sure you evaluate carefully whether you need a SQL
`back end and whether it's worth the tradeoff in performance. Local Visual FoxPro data
`access is likely to be two to three times faster than SQL Server data access (SQL 6.5) in
`most situations. It's one-and-a-half to two times faster with file data on a remote server. I'll
`talk more about the advantages and tradeoffs in the following section.
`
`• Minimize or offload long requests.
`Transaction-based systems work best with short requests. Long requests can tie up
`valuable resources and load up CPUs, which can very quickly bring a server to its knees.
`Try to break up lengthy requests into multiple smaller requests if possible. If that's not an
`option, consider off-loading long-running requests to other servers (perhaps a special
`maintenance server) or possibly a SQL Server. Keep in mind that any resource-draining
`operation has the potential to lock up your site because serious slowdowns and CPU load
`problems are self-perpetuating. As the server can't keep up, new requests pile up more
`quickly than the server can handle, resulting in an endless cycle of catching up.
`
`Smart Mobile Technologies LLC, Exhibit 2014
`Page 2014 - 17
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`

`

`332
`
`Internet Applications with Visual FoxPro 6.0
`
`To SQL or not to SQL
`The question of whether to migrate an application to a SQL back end invariably comes up
`when dealing with high-performance server applications. When you think about back-end data,
`keep in mind that VFP has an amazingly fast data engine—if speed is what you're after, VFP is
`likely to be the best choice, while SQL Servers provide security and data stability.
`
`Using Visual FoxPro data
`There are good reasons to migrate to a SQL back end, but many applications may not have a
`need for them. FoxPro works well even against very large data sets, so take the time to test
`performance. Don't blindly jump to a SQL back end! Consider the following points:
`
`• Native data is great for server back ends.
`For server applications, it's appropriate to use Visual FoxPro as a local data source because
`only a small number of simultaneous VFP clients access the data at once. Data is usually
`local to the machine on which the server is running—or it's on a fast, low-volume network.
`Unlike many standalone network applications, in a Web application a data connection is
`not from the user to the database, but from the Web server to the data. The execution
`environment is also very controlled because data access occurs from a server rather than
`from end-user client machines. Many data-integrity issues that can crop up in typical
`network applications—with large numbers of clients stemming from configuration and
`client problems—are not an issue with server applications.
`
`• VFP performance is much better than SQL.
`Keep in mind that VFP has an amazingly fast data engine. If speed is what you're after,
`VFP may be the best choice. I worked on one application that, when I converted from
`local VFP data to a SQL back end, data access ran between two and three times slower for
`short requests and five to 10 times slower for complex queries and administrative tasks.
`Proper tuning of SQL Server (which took several outside consultants several weeks)
`brought this down a little, but still left SQL Server running nearly twice as slow on
`average. Where performance counts, Fox data is an excellent choice. Even if you are using
`SQL Server data, take advantage of the Fox engine by downloading and caching static
`data in local cursors to save round trips to the server.
`
`• VFP can handle large data volumes.
`I worked on one high-volume commerce site where VFP back-end data was used with
`servers peaking close to 750,000 back-end hits a day on a single, four-processor NT box.
`The actual day-to-day operations of running an online shopping site ran flawlessly.
`
`• VFP has problems only with batch updates against heavily used, live data.
`So, why switch to SQL if all is rosy? There are a few problems with VFP data access on
`operations that should normally be left to EXCLUSIVE use. On this project, there were
`issues dealing with the frequent data updates that performed large imports into live, online
`databases. Many of these operations could have been performed with EXCLUSIVE
`operation, but this wasn't possible due to the time these import operations were taking.
`