Вы находитесь на странице: 1из 439

MySQL ® Client-Server Applications with Visual FoxPro ®

Whil Hentzen

Hentzenwerke Publishing

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 booksales@hentzenwerke.com

MySQL Client-Server Applications with Visual FoxPro By: Whil Hentzen Technical Editor: Ted Roche Copy Editor: Nicole Robbins-McNeish Cover Art: “Teaching Tricks” by Todd Gnacinski, Milwaukee, WI

Copyright © 2007 by Whil Hentzen

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: 1-930919-70-0

Manufactured in the United States of America.

iii

Our Contract with You, The Reader

In which we, the folks who make up Hentzenwerke Publishing, describe what you, the reader, can expect from this book and from us.

Hi there!

I’ve been writing professionally (in other words, eventually getting a paycheck for my scribbles) since 1974, and writing about software development since 1992. As an author, I’ve worked with a half-dozen different publishers and corresponded with thousands of readers over the years. As a software developer and all-around geek, I’ve also acquired a library of more than 100 computer and software-related books. Thus, when I donned the publisher’s cap five years ago to produce the 1997 Developer’s Guide, I had some pretty good ideas of what I liked (and didn’t like) from publishers, what readers liked and didn’t like, and what I, as a reader, liked and didn’t like. Now, with our new titles for 2007, we’re in our tenth season. (For those who are keeping track, the ’97 DevGuide was our first, albeit abbreviated, season, the batch of six “Essentials” for Visual FoxPro 6.0 in 1999 was our second, and we've been publishing every year since.) John Wooden, the famed UCLA basketball coach, posited that teams aren’t consistent; they’re always getting better—or worse. We’d like to get better… One of my goals for this season is to build a closer relationship with you, the reader. In order for us to do this, you’ve got to know what you should expect from us.

You have the right to expect that your order will be processed quickly and correctly, and that your book will be delivered to you in new condition.

You have the right to expect that the content of your book is technically accurate and up-to-date, that the explanations are clear, and that the layout is easy to read and follow without a lot of fluff or nonsense.

You have the right to expect access to source code, errata, FAQs, and other information that’s relevant to the book via our Web site.

You have the right to expect an electronic version of your printed book to be available via our Web site.

You have the right to expect that, if you report errors to us, your report will be responded to promptly, and that the appropriate notice will be included in the errata and/or FAQs for the book.

Naturally, there are some limits that we bump up against. There are humans involved, and they make mistakes. A book of 500 pages contains, on average, 150,000 words and several

iv

megabytes of source code. It’s not possible to edit and re-edit multiple times to catch every last misspelling and typo, nor is it possible to test the source code on every permutation of development environment and operating system—and still price the book affordably. Once printed, bindings break, ink gets smeared, signatures get missed during binding. On the delivery side, Web sites go down, packages get lost in the mail. Nonetheless, we’ll make our best effort to correct these problems—once you let us know about them.

In return, when you have a question or run into a problem, we ask that you first consult the errata and/or FAQs for your book on our Web site. If you don’t find the answer there, please e-mail us at booksales@hentzenwerke.com with as much information and detail as possible, including 1) the steps to reproduce the problem, 2) what happened, and 3) what you expected to happen, together with 4) any other relevant information. I’d like to stress that we need you to communicate questions and problems clearly. For example…

“Your downloads don’t work” isn’t enough information for us to help you. “I get a 404 error when I click on the Download Source Code link on www.hentzenwerke.com/book/downloads.html” is something we can help you with.

“The code in Chapter 10 caused an error” again isn’t enough information. “I performed the following steps to run the source code program DisplayTest.PRG in Chapter 10, and I received an error that said ‘Variable m.liCounter not found’” is something we can help you with.

We’ll do our best to get back to you within a couple of days, either with an answer or at least an acknowledgment that we’ve received your inquiry and that we’re working on it.

On behalf of the authors, technical editors, copy editors, layout artists, graphical artists, indexers, and all the other folks who have worked to put this book in your hands, I’d like to thank you for purchasing this book, and I hope that it will prove to be a valuable addition to your technical library. Please let us know what you think about this book—we’re looking forward to hearing from you. As Groucho Marx once observed, “Outside of a dog, a book is a man’s best friend. Inside of a dog, it’s too dark to read.”

Whil Hentzen Hentzenwerke Publishing July 2007

v

List of Chapters

Chapter 1: Why Client-Server? Why VFP? Why MySQL?

1

Chapter 2: Development and Deployment Scenarios

17

Chapter 3: Installing MySQL on Windows

25

Chapter 4: Installing MySQL on Linux

55

Chapter 5: Configuration of Users and Hosts

75

Chapter 6: Connecting VFP to MySQL

93

Chapter 7: Configuring MySQL

119

Chapter 8: The Interactive Use of MySQL

151

Chapter 9: Under the Hood: Where MySQL Keeps Its Data

173

Chapter 10: Creating Data Sets from Scratch

181

Chapter 11: Populating a MySQL Database: LOAD DATA INFILE

211

Chapter 12: Populating a MySQL Database Programmatically

219

Chapter 13: Advanced Data Issues

249

Chapter 14: Constructing SQL to Avoid SQL Injection

263

Chapter 15: Religious Wars: Remote Views, CursorAdapters, and SQL PassThrough

271

Chapter 16: A Client-Server State of Mind

287

Chapter 17: xBase to SQL Conversion Issues

295

Chapter 18: A Client-Server User Interface for Querying

317

Chapter 19: A Client-Server User Interface for Add/Edit/Delete

335

Chapter 20: Relational Integrity

369

Chapter 21: Getting Started with Stored Procedures

379

Chapter 22: Deployment

393

vi

vii

Table of Contents

Our Contract with You, The Reader Acknowledgments About the Author How to Download the Files Introduction

 

iii

xvii

xix

xxi

xxiii

Chapter 1: Why Client-Server? Why VFP? Why MySQL

1

What is Client-Server? Why Client-Server? Data access and security Backup Replication Clustering Stored procedures Referential integrity Scalability What is VFP? Why VFP? Technical reasons Business reasons What is MySQL? Why MySQL? Technical reasons Business reasons Arguments against FoxPro is dead (or obsolete, or not supported, or Visual FoxPro won’t have a native 64 bit version ODBC is too old/slow MySQL’s ‘SQL’ is not compliant or standard Conclusion/Summary

 

2

3

3

3

3

3

3

4

4

4

5

5

8

9

9

10

11

12

)

12

13

13

14

15

Chapter 2: Development and Deployment Scenarios

17

The big picture of how pieces fit together

17

The components

17

Visual FoxPro

18

ODBC Drivers

19

MySQL

19

The scenarios

20

Development

20

Production

23

Conclusion/Summary

24

viii

Chapter 3: Installing MySQL on Windows

25

Software and environment

25

The big picture – what installation does

25

The essential installation process

26

Read the documentation

26

Download files

26

Decide on a target location

26

Grab the files

27

Verify the bits

30

Uninstalling an old MySQL installation

30

Stop the service

30

Remove the service

31

Install the MySQL files with the installer

31

The Setup Wizard

31

Instance Configuration Wizard

38

Potential problems

47

Firewall troubles

47

Anti-virus conflicts

49

Collisions with a prior installation

50

Installation results

52

MySQL files have been installed

52

MySQL service created and started

53

Conclusion/Summary

54

Chapter 4: Installing MySQL on Linux

55

Software and environment used

55

The big picture – what installation does

55

The essential installation process

56

Read the documentation

56

Download the files

57

Decide on a download target

58

Grab the files

58

Verify the bits

62

Uninstalling an old version

62

Install the files

64

Install the server

64

Install the client

65

Set a password for the MySQL root user

66

Potential problems

66

Firewall conflicts

66

Installation with Fedora Core 5/6

67

Installation results

69

MySQL files have been installed

69

The Linux user account is created

70

Data files are created

71

ix

Automatic startup entries are created

72

The mysqld daemon is started

73

Conclusion/Summary

74

Chapter 5: Configuration of Users and Hosts

75

Work with the server from the command line

75

Windows and Linux command line tools

75

Running MySQL scripts

76

Summing up

83

The MySQL interactive environment (MySQL monitor)

83

Enter the MySQL interactive environment

83

Exit the MySQL interactive environment

84

A quick tour of the MySQL monitor

85

Set passwords and new accounts

86

Quickly adding a user

86

MySQL password concepts

87

How MySQL user passwords affect commands

89

Adding a work-a-day user

90

Conclusion/Summary

91

Chapter 6: Connecting VFP to MySQL

93

Installing the MySQL ODBC driver

93

Uninstalling an old version of the MySQL ODBC driver

93

Downloading the MySQL ODBC driver

93

Installing the MyODBC driver

94

Connecting to MySQL from VFP

99

Connecting to MySQL from VFP with a DSN

99

Connecting to MySQL from VFP with a connection string

108

DSNs or connection strings?

114

Initial tests with Visual FoxPro and MySQL

114

Creating a database

115

Where is the data created?

116

Working with tables in our new database

116

Conclusion/Summary

118

Chapter 7: Configuring MySQL

119

The MySQL configuration file

119

my.ini in Windows

119

my.cnf in Linux

121

Downloading the MySQL Administrator

122

Installing the Administrator

124

On Windows

124

On Linux

128

Running the Administrator

131

Advanced login options

133

x

The Administrator

140

Editing the my.ini/my.cnf file directly

147

Specific settings in the MySQL configuration file

148

Conclusion/Summary

149

Chapter 8: The Interactive Use of MySQL

151

Installation of the MySQL Query Browser

151

Windows download

151

Linux download

152

Windows installation

152

Linux installation

156

Using the Query Browser

156

Starting the Query Browser

156

Startup Errors

159

Parts of the Query Browser

161

Functions of the Query Browser

167

Other Tools

170

Conclusion/Summary

171

Chapter 9: Under the Hood: Where MySQL Keeps Its Data

173

Types of MySQL data

173

Where is your data?

173

Windows

174

Linux

175

Where is the MySQL metadata?

176

MyISAM

176

InnoDB

177

Where is the MySQL privilege data?

177

Moving your Windows data out of Program Files

179

Conclusion/Summary

180

Chapter 10: Creating Data Sets from Scratch

181

Best practices in database design

181

Relational database theory

181

Naming conventions

182

Keys

183

Time stamps

184

Overloading tables

184

Choosing data types

185

Available data types in MySQL

186

Comparing MySQL data types to VFP's choices

189

Making the decision

190

Creating your database from scratch

190

Creating a database

191

Creating tables

192

xi

Field attributes

195

Indexes

198

Creating primary keys

199

Assigning foreign keys

200

Working with time stamps

205

End result: empty data set – what's it look like?

206

mysqlshow

206

SQL commands

207

Getting data into the database

210

Conclusion/Summary

210

Chapter 11: Populating a MySQL Database: LOAD DATA INFILE

211

The MySQL LOAD DATA INFILE command

212

Where do I run the command?

212

LOAD INFILE Syntax

213

Handling primary keys

214

Leading spaces

214

Date and date-time fields

214

Handling BLOBS and TEXT fields

215

Conclusion/Summary

218

Chapter 12: Populating a MySQL Database Programmatically

219

Converting DBF data to MySQL

219

An overview of the process

220

Setting up the MySQL tables for this chapter

220

Description of the sample database

220

Sample source code

222

A

simple program skeleton

223

The SQLEXEC command

224

Formatting commands for SQLEXEC

224

Converting to a string for SQLEXEC

224

Using variables

225

Handling multiple data types

226

Tip: Getting the structure of an existing MySQL table

227

A

better way to format SQL commands for SQLEXEC

227

Creating the sample MySQL database

229

Drop the existing tables

229

Create the tables

230

A simple, one table migration

231

Using SQL INSERT to copy data

231

Putting the INSERT in context

231

A

bit of complexity

232

Sample migration with multiple data types

234

Dealing with special characters

234

Dealing with dates

235

Handling BIT fields

236

xii

Adding error trapping to the migration process

236

Alert about the error

236

Using AERROR() in a program

237

What should the program do?

239

Debugging the error

240

Not all errors are bad!

241

Error handling is just the start

242

Reorganizing the migration code

243

Handling SQL commands that are executed once

243

Handling SQL commands that are executed multiple times

244

Passing long strings

246

Moving more than data

246

Performance issues

247

Conclusion/Summary

248

Chapter 13: Advanced Data Issues

249

BIT field operations

249

Strategic use of BIT fields to replace VFP logicals

249

A bit arithmetic and functions primer

250

Define a BIT field

252

Putting data into a BIT field

253

New functions for modularizing code

253

Get data out of a BIT field

254

To extract just one position

256

To input just one position

257

New functions for creating cursors

257

When to use BLOB fields to store files

258

Infrastructure

258

Permanence and incremental backups

258

File size

259

Dealing with NULLs

259

What is a NULL?

259

Setting up a NULL

260

ENUM fields

261

Conclusion/Summary

261

Chapter 14: Constructing SQL to Avoid SQL Injection

263

How SQL Injection works

263

Improperly trapped delimiters

264

Direct injection: failure to validate data

265

Quoted injection: failure to trap data type

266

Database engine defects

266

Solutions to SQL Injection

266

Validate the data

266

Parameterized queries

267

Additional defenses

269

xiii

Conclusion/Summary

Chapter 15: Religious Wars: Remote Views, CursorAdapters, and SQL PassThrough

270

271

Remote Views

271

How to use

271

Pros

282

Cons

282

CursorAdapter

283

How to use

283

Pros

284

Cons

284

SQL PassThrough

285

How to use

285

Pros

285

Cons

285

Decision time

285

Conclusion/Summary

286

Chapter 16: A Client-Server State of Mind

287

A bird’s-eye view of a client-server application

288

Startup

288

Menu

288

File card forms

288

Action-oriented forms

290

Connecting to the back end

290

Selecting a subset of records

290

Writing back to the database

291

Adding

291

Deleting

291

Updating

291

Closing the connection

292

Conclusion/Summary

293

Chapter 17: xBase to SQL Conversion Issues

295

Architecture

295

Intermixed xBase

295

SQL commands

295

Central data access mechanism

295

Built with views

297

Command comparison

297

SQL commands

297

xBase commands

299

Function cross reference

299

Interactive evaluation of MySQL functions

300

xiv

Math functions

301

Lists, comparison, logic functions

303

Empty/Blank/NULL functions

305

Data/database functions

305

String functions

307

Date functions

310

System information functions

314

Miscellaneous functions

315

Conclusion/Summary

315

Chapter 18: A Client-Server User Interface for Querying

317

The logical and physical components

317

Source code

319

Base classes

319

Simple navigation form

320

Simple navigation with children form

321

Simple navigation with filter

322

Simple navigation with MySQL back end

325

Pass connection parameters to simplenav_withmysql1

326

Store connection handle in simplenav_withmysql2

326

Simplenav_withmysql2.init()

326

CreateConnection()

327

GetResults()

327

TableToForm()

329

Close()

330

Where do you create connections?

331

Trade-offs for child and minor entity relationships

332

Child tables

333

Minor entities

333

Conclusion/Summary

334

Chapter 19: A Client-Server User Interface for Add/Edit/Delete

335

Creating a class library for client-server functions

335

Building a simple for to add records

336

User interface

336

Internal design

337

Saving data

338

A simple two table edit form

339

User interface

340

Internal design

341

Displaying data on the form

341

Saving data

343

A simple two table delete form

345

Denormalized table issues

346

The Delete() method

347

xv

Design of an all-in-one form

350

Internal design

352

Adding and deleting minor entities

354

Adding a business

354

Deleting a business

355

Adding and deleting business types

357

Adding and deleting contacts

360

Tricks and Tips

362

Retrieving empty dates from MySQL

362

Retrieving null dates from MySQL

363

Handling full outer joins in MySQL

363

Selecting number of records in a result set

365

Using auto-increment to handle primary key

365

Determining the last value of an auto-increment field

366

Conclusion/Summary

367

Chapter 20: Relational Integrity

369

Revisiting the interface

369

Creating foreign key constraints

371

Using foreign key constraints

374

Using RI interactively

374

Using RI in a VFP form

375

Errors encountered during RI setup

375

InnoDB only!

376

Indexes needed on both side of FK expression

376

Index fields need to be same type, and maybe length

376

Constraint name needs to be unique

377

Conclusion/Summary

377

Chapter 21: Getting Started with Stored Procedures

379

What is a stored procedure

379

Creating stored procedures in MySQL

379

Make sure MySQL is set up for stored procedures

379

Create your very own stored procedure

381

Run the proc from the MySQL monitor

382

Create a procedure that accesses a database table

383

A stored procedure with a parameter

383

Passing a parameter, somewhat more involved

384

Using a parameter more constructively

384

Using input and output parameters

385

Cleaning up

385

Where is a stored procedure stored?

387

Calling a MySQL stored procedure from VFP

387

Calling your basic stored procedure from VFP

388

Passing a hard-coded parameter to a stored procedure

389

Passing a user-provided parameter to a stored procedure

389

xvi

Incorporating stored procedures in the sample app Conclusion/Summary

390

391

Chapter 22: Deployment

393

Getting started

393

Development

394

Build your application’s EXE with VFP

394

Create an installation package for your application

394

Production server

395

Install production MySQL server

395

Configure the production MySQL server user

395

Install production data

397

Open firewall for port 3306

400

Client machine

400

Install the application

400

Test connection to the server

400

Licensing

401

Internal applications

401

Consultant

402

The GPL

402

What next?

403

Conclusion/Summary

403

xvii

Acknowledgments

A book isn’t just the result of the author staying up late at night with the Megaslurp-size of Jolt Cola and a bucket of Doritos by his side. Many folks are involved with the production of the book, from the initial formulation of the content all the way through the last application of spit and polish on the final manuscript. This book, even more so.

I’ve been writing books since, oh, before there was paper, it seems. (1992 is the actual year, if you want to Magellan it on the Web). In those days, the process for writing a book adhered to a well-traveled formula. The author wrote a chapter, sent it to the publisher, who forwarded it to the technical editor, who returned it to the publisher, and back to the author, who had already been hard at work on the next chapter. Once the review of tech-edits was complete, the process was repeated, but with the chapter going back to the publisher for copy edit instead. And then the cycle was repeated again for layout, and then page proofs. This cycle kept the author on their toes and ensured that the book would be produced on time, but tended to drive most of the folks in the chain crazy – despite an initial outline that helped the author win the gig, the author often didn’t authoritatively know what Chapter N was going to contain until Chapter N+1 was drafted. And let’s not get started on trying to produce content about a product that was still in early beta testing. I used to have hair, before trying to write a book on Visual FoxPro 3.0. One big part of the book writing cycle was that the existence of the book was a secret. Oh, sometimes an author would let on that they were working on ‘something’, and as the software (and book publishing) industry matured, general topics became known. But details, no, they were kept behind closed doors, very hush-hush, eyes-only, and all that. We kind of broke that mold when we started offering pre-release chapters of our early Visual FoxPro 6.0 books in 1998, so people could get their hands on material before the book was finished. That proved popular, although more of an administrative headache than we planned on. Still, after a dearth of VFP books in the mid-90s, any new content was gladly welcomed, no matter how rough it was at first. Then the Internet happened, and with it, new expectations for publishing. One upside of those new expectations was collaborative development of documentation. So instead of trying to write this book in a closet and then release it to an unsuspecting world when I deemed it complete, I opened up the writing process, similar to the way Tom Rettig provided access to his third party framework, Tom Rettig’s Office, while it was under development. Over a hundred folks answered the initial call, and despite a couple of time spans where other projects slowed down progress on this book, a couple dozen stuck with me for a significant part of the gig. In no particular order, the following folks suffered with me through 2006 and beyond, and contributed something notable toward this book:

Vassilis Aggelakos, Larry Bradley, Joel Chaban, Joe Cross, Hernan E. Delgado, Ray Del Prado, Bill Ganger, Matt Jarvis, Chris Jefferies, Carl Karsten, Bob Klein, Tony Kovalik, Bob Lee, David Masri, Brent Mattox, Ed Pecyna, Eric Selje, Bill Sherman, Phil Sherwood, Ken Srigley, Arden Weiss, and Bud Wheeler.

xviii

Oh, wait, that’s alphabetical order, isn’t it? Still, every person contributed something special for this book, and I thank each of them. But, wait, there’s more! I want to mention the specific contributions of Dave Bartkus and Iames Pizzoli were as particular as reviewers as I’ve run across, constantly finding missing words, typos, and misspelled words. It eventually became a challenge to produce a chapter that either wouldn’t return full of edits. (Never succeeded.) Ron Gafron asked many real world questions, making sure I wasn’t getting bogged down in the details and missing the larger view for someone new to client-server and MySQL. Andy Kramek passed along many tidbits of client-server wisdom; his years of building big applications showed through regularly. Pat Mazuel steadily worked through every chapter, despite work, travel, and holiday commitments, acting as the architypical developer-reader I’d hoped for. Randy Pearson gave me a couple of well-needed slaps upside the head about SQL Injection. Nicole Robbins-McNeish, my copy-editor, proof-reader, and layout artist, who again turned what I thought was pretty good prose into something measurably better, and Todd Gnacinski, the hand behind the artwork of all but four Hentzenwerke Publishing covers (the exceptions being HackFox 6 & 7, and the first two DevGuides) – every book is another reason to see what Todd’s got up his sleeve. And last, but certainly not least… Ted Roche, whose contribution can’t adequately be described in words. Ted and I met on a bus on the way to Martin Schiff’s pre-DevCon party in Florida in 1992, and nary a week has gone by since without an exchange between us. Ted has been that perfect reviewer, some would say ‘coach’, alternating “Atta-boys” with “Are you sure about this?” and “Who are you trying to con?” and “Nice try, now go back and try again - the right way.” As I said in a recent email, “I open every chapter I get from you with trepidation, relieved at – while simultaneously dreading – your refusal to cut me any slack.” Thanks, dude. And finally, this time around on the “NP” list – the B-52s, Meat Loaf, Aerosmith and B.B.King. Looking back at the acks for my first book, I see things haven’t changed that much. You know what they say about writing software. Whil Hentzen Milwaukee, WI

xix

About the Author

Whil Hentzen

Whil Hentzen fills the role of “player-coach” at Hentzenwerke Publishing, a 9 year old Milwaukee-based publisher that specializes in titles covering high-end software development and, more recently, the migration of Windows developers and users to Linux. Whil started out life as a custom software developer using dBASE II (he still has the original 8 1/2 x 11 grey binder of documentation, much to the chagrin of his wife), and switched to FoxPro in 1990. As an independent Fox developer, he billed over 15,000 hours in the 90’s, including the requisite “1,000 hours in 3 months” Y2K emergency gig while recovering from leg surgery. During that time, he presented more than 70 papers at conferences throughout North America and Europe, edited FoxTalk, Pinnacle Publishing’s high end technical journal for 7 years, and hosted the Great Lakes Great Database Workshop since 1994. In 1999, Microsoft contracted with Whil to co-author the Certification Exam for Visual FoxPro 6.0 Distributed Applications, which has since been taken by thousands of developers to help them achieve Microsoft Certified Solution Developer credentials. He was a Microsoft Most Valuable Professional from 1995 through 2003 for his contributions to the FoxPro development community, and received the first Microsoft Lifetime Achievement Award for Visual FoxPro in 2001. He started writing in order to develop credentials to bolster his software development career. His first book, Rapid Application Development with FoxPro, showed up in 1993, and seven more have appeared since. He started Hentzenwerke Publishing in 1996 to self-publish a specialized volume on software development, and then began producing Visual FoxPro books when the major publishers abandoned the market in 1998. Sensing the impending acceptance of Linux on the desktop and anticipating a coming demand for custom business applications on those Linux desktops, he turned his attentions to Linux in 2002, and now has eight narrowly targeted Linux and open source books available. Despite being HQ’d in Whil’s house, HWP’s backlist now numbers close to 40, with some 70 authors and editors worldwide on the payroll. He currently splits his time between freelance custom development with Visual FoxPro and a host of open source tools such as MySQL, PHP, and Python, and running the publishing side of the biz. Whil has a B.S. in Mechanical Engineering from Rose-Hulman Institute of Technology, named as the United States’ top independent engineering school every year since 1999 by U.S. News & World Report. He served on RHIT’s Commission on the Future from 1993 to 1998. He currently spends his copious amounts of spare time with his five kids and volunteering for the local school district. An avid distance runner, he has logged over 50,000 miles lifetime, and, pending recovery from yet another injury-du-jour, hopes for one more shot at a competitive 5,000-meter clocking before age and common sense close the door on that activity. You can reach Whil at whil@hentzenwerke.com or at 414.332.9876.

xx

Ted Roche

Ted Roche is the owner of Ted Roche & Associates, a software development and consulting company based in Contoocook, New Hampshire, USA. TR&A develops and maintains database-intensive web sites and rich-client applications for clients in a range of industries from wholesale commodities to produce to financial services, manufacturing, and insurance. A former nine-time Microsoft Most Valuable Professional, Ted now spends his time developing Free / Open Source solutions using Linux, Apache, MySQL, PostgreSQL, PHP, Python, and Ruby. If you’d like to contact Ted for help on your project, his contact information can be found at http://www.tedroche.com In his spare time, Ted is the leader of the Central New Hampshire Linux User group and a board member of the Greater New Hampshire Linux User Group, http://www.gnhlug.org.

xxi

How to Download the Files

Hentzenwerke Publishing generally provides two sets of files to accompany its books. The first is the source code referenced throughout the text. Note that some books do not have source code; in those cases, a placeholder file is provided in lieu of the source code in order to alert you of the fact. The second is the e-book version (or versions) of the book. Depending on the book, we provide e-books in either the compiled HTML Help (.CHM) format, Adobe Acrobat (.PDF) format, or both. Here’s how to get them.

Both the source code and e-book file(s) are available for download from the Hentzenwerke Web site. In order to obtain them, follow these instructions:

1.

Point your Web browser to www.hentzenwerke.com.

2.

Look for the link that says “Download”

3.

A page describing the download process will appear. This page has two sections:

Section 1: If you were issued a username/password directly from Hentzenwerke Publishing, you can enter them into this page.

Section 2: If you did not receive a username/password from Hentzenwerke Publishing, don’t worry! Just enter your e-mail alias and look for the question about your book. Note that you’ll need your physical book when you answer the question.

4.

A page that lists the hyperlinks for the appropriate downloads will appear.

Note that the e-book file(s) are covered by the same copyright laws as the printed book. Reproduction and/or distribution of these files is against the law.

If you have questions or problems, the fastest way to get a response is to e-mail us at booksales@hentzenwerke.com

xxii

Introduction xxiii

Introduction

Where I tell you what you're going to get out of this book, and some housekeeping notes. Blah, blah, blah

I built my first real-live client-server application as part of a Y2K emergency bailout for a

customer. The customer had contacted me in late 1998 with the desire to merge a number of disparate systems, both home-grown and outsourced, into a single coherent application. The company’s growth had recently accelerated; the firm had gone from a single quonset hut-based

headquarters to manufacturing plants overseas and branch offices throughout the States in just

a couple of years. Their systems hadn’t kept pace. Naturally, with the spectre of Y2K looming, the first question I asked was whether they had any Y2K issues looming. “No.” they declared. “None whatsoever. We’ve been through every application we use and we’re in good shape. Take your time and do it right.” So we began design, merging just about every department’s stand-alone application into a single system that would mesh with their existing vertical market accounting and sales call management applications. Summer of 1999 arrived, prototypes were rolled out and accepted, and we were ready to start coding. Fall approached, and new versions of the accounting and call management apps were installed. SQL-Server based versions. “We know that you’ve already started the programming, but how hard would it be to convert your system to use SQL-Server as well?” they asked. This wasn’t really a question, of course. Okay, this was going to be interesting. They understood that there was going to be some

additional time needed to retool the interface, and I was going to be putting in some extra hours putting into practice for someone else what I had to that point only used internally. But we all have to start somewhere. Progress continued, and I was confident enough to schedule leg surgery six weeks out, just before Thanksgiving. As the kids started discussing Halloween costumes, the meeting to install the first beta version was scheduled. I arrived to find everyone gathered around a conference table. “I know you were planning on showing us the first beta today, but we have something

else we need to discuss.” My stomach twisted; I could imagine the worst

out of business, they decided they weren’t happy with my work, they ran out of money, they were moving their headquarters, a new management team had taken over the company, who knew what it was going to be? “Our inventory system is going to shut down in 78 days. It turns out it’s not Y2K compliant after all. We need to have your entire system up and running by holiday shutdown

on December 23.”

They were going

Nothing like a bit of pressure to help focus one’s mind, eh? I wrote a lot of remote views and tested performance with queries simultaneously hitting

three separate SQL Servers that fall

the customer as I hobbled in with crutches wearing off quicker than you’d imagine. With the aid of a lot of duct tape and bubble-gum (and an understanding customer when yet another late night short-circuited the brain-keyboard connection), we were able to stitch up

enough of the system for them to flip the switch over holiday shutdown and go live. The rest of

much of it with my leg wrapped up; the pity factor with

xxiv

MySQL Client-Server Applications with Visual FoxPro

the winter was a lot of clean up work and patching the holes, but the system was solid by spring; enough that I was able to turn over the keys to the source code before summer. I mention this not only because it’s a great Y2K story, and not just because it explains why I never want to see another Remote View as long as I live, but because it goes to show that building a big client-server isn’t that much more difficult than the traditional LAN application that you’re already used to. As the saying goes, “After you understand the

concepts, it’s just syntax.” And this book is about the concepts (together with some sample code to show you the syntax.) It’s the book I wish I had when I was starting out with client-server development a decade ago. A couple of notes about what’s inside before we get started:

1. First of all, please see “How to download the files” for instructions on how to grab

files from our website. The source code consists of one big ZIP file that consists of separate ZIP files for each chapter. Check out the “README.TXT” files inside each chapter’s ZIP file

for details.

2. The screen shots and URLs throughout this book were current as of the writing and/or

printing. Depending on when you are reading this, they might have changed. (“Might have”?

Of course they have!)

3. I’ve written a number of articles that you might find useful; they can be found under the

“Resources” link on our website. Expect to see some on MySQL as follow-ups to this book.

That’s all for now. Enjoy the ride.

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 1

Chapter 1 Why Client-Server? Why VFP? Why MySQL?

VFP and MySQL make an incredible combination for fat-client, client-server and Web applications. However, Microsoft’s many years of marketing neglect has relegated VFP to near invisibility. Thus, its capabilities are largely unknown and its selection as a development tool has become a questionable choice in the eyes of many uninformed or prejudiced users. And MySQL, despite its growing acceptance in many areas of the IT arena, is still a relative newcomer in terms of mind-share with many US users due to its open source roots and European origins. This chapter explains why VFP and MySQL is a compelling combination, and gives you, the developer, ammunition for those “discussions” with management.

Since this book covers both VFP and MySQL, it’s likely that some readers are coming from an ‘experienced in VFP, inexperienced in MySQL’ perspective while others are more familiar with MySQL and less so with VFP. And it’s probable that some are new to client- server completely. As a result, after discussing client-server architecture in general, I’ll cover what each tool is and the benefits of using it.

This chapter provides a technical overview of client-server systems and both products as well as the business justification for all three – but for two very different audiences. First, I’m targeting folks who are new to one or more of these areas, giving them the big picture so that they may put the rest of the book in proper context. If you’re already experienced in one or more of these areas, you may be thinking that you can skip this chapter, but that may not be advisable. During the preview of this book, I received some feedback that indicated this chapter was unnecessary. Bud Wheeler of Visionpace summed it up nicely: “This is my least favorite chapter in every technical book. It always feels like something you have to get through before you actually get started. As the reader I want to skip this chapter, but then I never know if I am missing something important. I think you are preaching to the choir. The reader wouldn’t have the book if they weren’t already going to be using VFP and MySQL. The majority of this content could be presented as an appendix or in other chapters.” I thought about this for a while, and I can see the point of view. Frankly, I don’t like writing these types of chapters either – they’re more like marketing than technical, and if I wanted to be in marketing, well, you know the rest of that joke. But I decided to go ahead and do this chapter anyway. Sorry, Bud! Here’s why. First, as I mentioned in the abstract above, there are some folks who are new to the whole client-server thing, and they need an introduction to the topic that is tailored for VFP and MySQL. Next, some folks are likely to be experienced with one tool but not the other, and so still need some of the basic “What is and why?” information. For them, VFP or MySQL is a buzzword they’ve heard bandied about, but don’t know that much about. The purpose of this

2

MySQL Client-Server Applications with Visual FoxPro

chapter for them is to summarize what they could dig up in an hour elsewhere. That’s what

a book is, actually, isn’t it - a coherent synopsis of what you could find elsewhere if you had

the time? Finally, while you and I and the guy behind the door all know what marvelous tools VFP and MySQL are, not everyone is as blessed. More importantly, while you may know in your heart that you’ve made the right choice, you may not be able to succinctly convey that knowledge and feeling to others. Many of you will end up in a meeting and have to justify your choice of VFP (“I thought Microsoft killed it a long time ago!”) or MySQL (“MySQL? Isn’t that one of those commie ‘open source’ things?”). It’s easy to forget items if you’re trying to come up with a presentation for ‘the big meeting with management’ tomorrow morning. This chapter provides that presentation. Here is where you’ll find a (moderately) objective list of benefits to using VFP, MySQL, and the two of them together. This is the chapter you take into your boss as backup to buttress your case for your choice of tools. If you’re just kicking the tires for now, or if you’ve already made the decision and don’t need any support for it, then feel free to move along to the next chapter. For the rest of you, let’s take a new look at two of our favorite development tools.

What is Client-Server?

In a traditional file-server application (also called a LAN or fat-client application), the data is stored on the file server while the application itself runs on the user’s workstation. Because the workstation is used for processing, the application is used to provide sophisticated, powerful interfaces. The trade-off, however, is that the database is neither secure nor fault-tolerant. The file server is simply a repository for dumb files that happen to be database files, and thus are subject to the same types of malevolent access and inadvertent corruption as every other file on the server. In addition, something as simple as performing a query requires a lot of network overhead. Opening a table requires a hit to the file server. Then the index has to be opened and the keys determined – trip number two – possibly encompassing a lot of data if the indexes are large. Third, now that the index keys have been determined, the specific records requested need to be grabbed. That’s a lot of work and data going over the wire. If you have a lot of users and large databases, this can potentially bog down a network substantially. In a client-server application, the data is stored on the file server, but encapsulated inside an application so that only the application can access the data. The user (also called the ‘client’) simply sends a SQL statement to the database server, which then does all of the processing and returns the results – just the records that match the SQL statement. (In properly designed and configured systems, goofball scenarios – such as if

a SQL statement requested every record in a multi-million record table – are handled

appropriately.) As a result, the number of trips sent across the network is minimized, as is the

amount of data. Thus, in a client-server system, two separate applications are involved. The first application – the database server – runs on a physical server box. It protects and provides access to the data, which is also located on the server box. The second application – the client app – runs on the user’s workstation, and sends requests to the server, just like clients at a restaurant make requests of the waiter/waitress (the ‘food server’).

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 3

Why Client-Server?

As briefly discussed in the previous section, a client-server application can offer better performance than a corresponding file server application as well as better security. But there’s more. Let’s start at the beginning, though.

Data access and security

Data is protected by the database server (and, presumably, by restricted access to the physical server box as well.) Clients send requests (like SQL SELECTS, INSERTS, UPDATES, or DELETES) to the server. The server application receives those requests, does whatever processing is necessary, produces a result set, and sends those results back to the client. Access to the database is controlled by the server. Users can’t get to the data unless the server application allows them to. Servers themselves have multiple layers of security built in – first allowing access to the server, and then to the data on the server. MySQL also has the ability to restrict access from predefined clients.

Backup

Modern client-server databases provide the ability to do a live backup of the database while it is in use, which is difficult, if not impossible, to do with a file-system database like Visual FoxPro. While you can physically copy VFP files while they’re open, the duplicate files are subject to inconsistency even corruption if they’re being written to at the same the backup is taking place. With a client-server system, the engine takes care of writing an entirely separate copy of the database while making it consistent with writes from the user. The copy can then be moved to separate media, such as another server or tape.

Replication

Many larger systems require the use of multiple copies of the same database. Replication is the process where the data in one database is used to update another, physically separate, database. Suppose a company has installations of the system in various locations around the globe, some of which have tenuous network connections. Instead of requiring each location to rely on a single master copy of the database “back at headquarters,” each location can have their own copy, which is then synchronized with the master copy overnight.

Clustering

Clustering is the use of multiple systems to operate together, in order to spread the load among more than one box. The database file(s) can be located on more than one box, but the application acts as if they’re all in a single location. Many client-server systems provide clustering as a native feature, while accomplishing the same task in Visual FoxPro would require significant amounts of effort.

Stored procedures

Stored procedures are pieces of code contained with the database engine, and can either be called explicitly or executed by the database server engine as a result of an engine process. An example of the latter is the insertion of a new record. Stored procedures were commonly used for generating primary keys and handling child records when parents were deleted, until those functions were embedded directly in the engine itself. Some organizations require virtually all

4

MySQL Client-Server Applications with Visual FoxPro

access to the database to be done via stored procedures, using external applications only for querying and reporting. Properly written stored procedures can be valuable tools, as they move the processing demand to the presumably powerful server box instead of relying on a network and often widely disparate processing power on user workstations. Many database servers also allow stored procedures to be given security rights just like other objects in the database. Users can then only modify the database by going through the appropriately vetted stored procedure that is the only object that can touch the data.

Referential integrity

Referential integrity (“RI”) is the set of rules defined for handling changes, including but not limited to deletion, that could affect records related to the one actually being changed. RI can be handled several ways. One way is to depend on stored procedures executed by the insert, update, or delete of a record (known as triggers). Another way is to build RI into the database at the engine level (known as “declarative RI”), so records with linked records are simply not allowed to be deleted or modified in such a way that would leave the linked records with incorrect relationships. File based database systems like Visual FoxPro provide RI through the use of triggers while database servers like MySQL use declarative RI. The problem with triggers is their stored procedures are built by human programmers on a custom basis, which renders them more fallible than a mechanism built into the server, and thus, presumably, tested more fully by the company that manufactures the server.

Scalability

Client-server systems, by their very nature, are designed to handle hundreds, even thousands of users, and provide access to terabytes of data. With features like clustering and replication, client-server systems can natively handle the large majority of applications requiring large numbers of transactions with real-time response. There are other advantages to client-server architecture as well, but these are the major points you would be well advised to look at if you’re considering a move from a file-based architecture to a client-server setup.

What is VFP?

What is Visual FoxPro? Why, it’s a floor wax! No, it’s a dessert topping! No, it’s both! With that required remembrance from a Saturday Night Live skit of many moons ago out of the way, we can concentrate on what VFP is. Visual FoxPro is an application development tool that incorporates both a powerful and full-featured programming language and a native data engine. The language has its roots in the original end-user database manipulation program, dBASE II, from the early 1980s, and thus is tightly integrated with data handling. The major overhaul of the tool in 1994 that produced Visual FoxPro from FoxPro for DOS and FoxPro for Windows incorporated a new object- oriented syntax that allowed backward compatibility with older systems while allowing state- of-the-art development as well. VFP’s predecessor, FoxBASE, has long been used for building single user database applications since the mid 80s. FoxBASE morphed into FoxPro, running on DOS, Windows, Mac, and Unix around 1990, and became the tool of choice for building multi-user systems on

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 5

local area networks. Indeed, many of those systems written 15 years ago are still around today, faithfully serving their business needs without a hiccup. Visual FoxPro became the perfect front end for client-server systems with native language extensions in the early 90s. Finally, with third-party add-ons like Web Connection, VFP provided an excellent way to add Web functionality to a system in the late 90s. During the 90s, VFP was used for a number of well known, high profile applications:

CBS (Christian Broadcasting Company), based in Virginia, developed a system that stored 10,000,000 records in FoxPro for DOS. In 2007, that may not seem like a big deal, but in 1992, when the work-a-day machine sported a 386 processor and two to four megabytes of RAM, and was connected to a network via a 10 Mb card, this was an impressive feat. The Joint Flow and Analysis System for Transportation (JFAST) determines a variety of logistical modeling, including transportation requirements, source of action analysis, and delivery profile development, for the United States Military. Originally built on an IBM 370 mainframe computer, the development team turned to FoxPro when the 370 couldn’t perform fast enough. It produces reports that brief the Joint Chiefs of Staff during military operations, and has been personally demonstrated as an example of what is possible with Fox to industry executives like Fox Software founder Dave Fulton and Microsoft Chairman Bill Gates. The largest amount of data handled by a Fox application is 128 GB, the engineering database for the EuroTunnel underwater passageway between England and France. Surplus Direct, a mail-order retailer of computer hardware and software, began its Web appearance using Visual FoxPro and Web Connection. At its peak, VFP has handled as many as a million requests in a single day. In short, VFP can (darn nearly) do it all.

Why VFP?

Visual FoxPro (and its predecessors) has been the most powerful, fastest desktop development tool for nigh onto 20 years. The world has changed in that time, with Web-enabled and mobile applications becoming more and more important. However, the need for rich user interfaces that work with network-level databases hasn’t gone away – we’ve just gotten used to them, so they’re not in the news much anymore. Let’s take a fresh look at the benefits VFP has to offer.

Technical reasons

I’ve been developing database applications for local area networks, client-server systems, and Web systems for over two decades. Over the years, I’ve poked under the rocks of a half dozen different tools, and Visual FoxPro is still my favorite. Why? It’s a great development tool, built by a small group of folks who used to be Fox developers themselves. Here are some of the big reasons it’s a great choice for building client-server apps with MySQL.

Robust programming language Some would say too robust, in that there are literally thousands of commands and functions. Fortunately, since the core engine has stayed the same for the last decade, the development team has been able to spend their time tweaking and enhancing the existing toolset, instead of debugging a whole new build every couple of versions.

6

MySQL Client-Server Applications with Visual FoxPro

Full-featured IDE We take the Command Window – the ability to execute one or more lines of code interactively, for granted, but not all tools have it, and some have just acquired it recently. There’s also a great debugger with five separate windows, and the data session window, providing a view into tables and cursors with a single click.

Programming tools The coverage profiler, document view, and code reference tools – use some of them, use all of them – your choice, but they’re there as you need.

Object-oriented programming facilities These include a Properties GUI, visual and non-visual class tools, class and object browser, and a class library component gallery.

Extensibility Fox has always provided developer-accessible hooks in its development and run-time environments. You can hook into all of the developer tools, such as the form designer, menu builder, report writer, project manager, and others, as well as specify replacements for all of the programming tools just mentioned. For example, you can write a routine that automatically runs when you open a project in the Visual FoxPro project manager, or when you execute the build process. Another example is shown in Figure 1, where you see the pointers to various programming tools. You can write your own replacement and point VFP to use it instead.

write your own replacement and point VFP to use it instead. Figure 1 . You can

Figure 1. You can point to your own replacement for a variety of programming tools.

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 7

In addition, many of the native tools and components are written in Visual FoxPro itself, and the source code for all such components is provided. So, if you need alternative performance or functionality in one of those tools, you can rewrite it yourself.

Executable and COM component creation within IDE Some developer tools require you to shell out to another mechanism to do your application builds. This is all handled within VFP’s IDE, and it has hooks you can use to modify the process as needed for your own projects.

Native data engine Fire up VFP and you have direct access to the databases and tables at your fingertips in the IDE – no need to have an external data source installed and connected. (And you have access to that data through the afore-mentioned Command Window.) While that may seem counterproductive to a book that discusses VFP with a back-end database, what it means is you can use this internal data processing in your applications. Grab a record set off the server, and then use the local data engine to do processing and simply fire the result back to the server, or the user.

Data massage capability One of my reviewers pointed this out in a most fluent manner: “Visual FoxPro is still my favorite tool to get data massaged and migrated from one (or even better, multiple) sources to a target data environment. For example, moving data from DBFs, Excel, Access, text files, or whatever other format you have your data in – it’s a snap to move it to MySQL, MS SQL Server or Oracle. The main reason is that it has the best string manipulation functions of any of the other tools I’m aware of. “Combine this with the friendly Command Window, which lets you run single commands or groups of commands in interactive mode from either native DBFs or any ODBC-capable data source. It’s ridiculously easy to select data from a varied set of sources into one or more cursors, and then process them one record at a time and use SQL pass-through SQL INSERT statements to move the results into the back end.” If you have used other tools to migrate data from one place to another, you, too, know how powerful Fox is – much like the difference between pen-and-paper spreadsheets compared to that new-fangled electronic spreadsheet that Bricklin and Frankston invented in the late 70s.

Rushmore technology Oh yeah, that. We often forget that VFP is still the fastest desktop database in the solar system. Introduced over a decade ago, this patented technology provides sub-second responses to queries against multi-million record tables. While that may not seem like a big deal in 2007, that speed could be obtained on run-of-the-mill laptops in the mid-90s. And Fox has only gotten faster. This means internal processing of data sets of virtually any size is instantaneous.

ActiveX extensions and Web services VFP applications can include outside tools and functionality via ActiveX controls, just like Visual Basic and other ActiveX enabled tools. Fox can also develop and consume Web services as well as use SOAP, if you’re so inclined.

8

MySQL Client-Server Applications with Visual FoxPro

Processing speed VFP has long been heralded for its data access speed. But that’s not all it’s fast at. Text processing operations, like the kind you’d use to build HTML output, has been significantly enhanced over the years. You’ll see that iterating through a loop 10,000 times while building a string is done instantaneously – smaller jobs are finished even faster. Quite a remarkable achievement for a 4GL (Fourth Generation Language.)

Stability Some tools are rewritten every couple of versions, either to make up for the problems that surfaced after the last rev’s ‘hurry up and get it out the door’ approach have come back to roost, or simply to incorporate new features that couldn’t be added any other way. VFP’s core engine has been around for over 15 years. As a result, the product is incredibly stable.

Backward compatibility The Fox team has always taken great pains to make sure new versions didn’t break old code. This is part of the reason the language has become so huge (some say ‘bloated’, for which an argument can be made), but it also means the code base has been tested exhaustively.

This list just touches the surface, but I think it hits some of the key points other technical folks would be interested in. See the following URL for a detailed list of features:

http://msdn.microsoft.com/vfoxpro/productinfo/features/default.aspx

Business reasons

I’m going to keep this one short, as management, unlike the techies who will be interested in the ‘technical reasons’ just covered, sometimes has a limited attention span. Two (or three) big points are about all you’ll have time for.

Long life span An app you build (or rewrite) today can be expected to have a lifespan of at least a decade. How many VB apps from ten years ago are still in production?

Inexpensive to deploy On the Fox side, you build an app and deploy the EXE as many places as you want. Total dollars out of pocket (in terms of license fees back to Microsoft) to do so: $0. (This is one major reason why MSFT won’t promote VFP – there’s no financial incentive – “client access license fees” – to do so.)

RAD VFP is the original Rapid Application Development toolkit, and has been that way for a long, long time. Building systems in VFP, if you have the requisite skill set, is fast. Really fast. Poke around on any VFP-related mailing list and you’ll find instance after instance of a Fox developer creating an application several times faster than the other team slated to do the same gig in another tool/language. But the converse doesn’t ever seem to happen. I have never seen Fox booted out of place for technical reasons – rather, the motive always ends up on marketing’s lap – “It’s not strategic” or “It’s not .NET.” You never see stories about how it took a Fox developer five

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 9

times as long to build a system as the guy next door using Visual Basic or Java or C++. Why spend nine months building an app that can be done in three?

Community support The average Visual FoxPro developer can truthfully be called zealous in terms of their passion for the product; some unkind folks use monikers such as ‘rabid’, ‘fanatical’, or ‘possessed’. Whatever the case, the end result is that this passion has translated into a large community of very helpful and knowledgeable users who are available on-line through electronic forums and mailing lists, and in person at conferences and user groups.

What is MySQL?

MySQL is a database server that competes in the same general arena as other mid-market database back-ends, such as Microsoft SQL Server, PostgreSQL, and Sybase. (Don’t confuse these with the high-end, dedicated big-iron database engines like Informix, Oracle, and IBM’s DB2.) Developed by the company MySQL A.B., which was founded by two Swedes and a Finn, the company is based in Sweden and has a dozen offices in major countries throughout the world. MySQL comes in several flavors. The MySQL Pro Certified Server is designed for enterprise and mission critical database applications. The MySQL Community Edition is for open source developers who want to get started with MySQL. The MySQL Cluster version provides fault tolerant database clustering. This book will cover the Community Edition, as it is freely available under the open source GPL license. I’ll cover when you need to consider licensing the Pro edition in Chapter 22, Deployment. As with other database servers, MySQL encompasses more than just the database server. You can also download a variety of add-ons, such as the MySQL Administrator, which allows you to edit the MySQL configuration file graphically, a Query Browser, which is similar in purpose to Microsoft SQL Server’s Query Analyzer, and a Data Converter, which can help moving data from another database backend. MySQL claims to be the world’s most popular open source database server, and while I doubt they’ve gone out and tallied up how many of which server is running on every box in the world, there’s no argument that it’s hugely popular and can be found in every nook and cranny of the IT world. It’s as close to a corporate standard as there can be. Who is using MySQL? There are lots of case studies on the MySQL website here:

http://www.mysql.com/why-mysql/case-studies/

While some of the companies aren’t exactly household names, plenty of others are, and they all serve to demonstrate the wide variety of systems relying on MySQL as their database.

Why MySQL?

This question can be interpreted two ways. The first is, “Why use a back-end database server instead of relying on VFP tables?” The second is, “If you decide to use a backend database server, why use MySQL instead of (fill in the blank with the name of a competitor or three)?” The reasons to the first question generally fall under the technical category while the reasons to the second generally end up under the business reasons domain.

10

MySQL Client-Server Applications with Visual FoxPro

Technical reasons

There are several classic reasons to move to a back-end database server from VFP.

Limitations to the DBF: size, security, stability The first that comes to mind is the size limit of Visual FoxPro tables. A single file (DBF, FPT, or CDX) can’t be larger than 2 gigabytes, due to the internal architecture of VFP. (Who decided back in the 1980s that we wouldn’t need to use tables over 2 GB in size? Undoubtedly the same folks who knew we’d never need more than 640K of RAM.) MySQL (and other database servers) have limits that boggle the mind, perhaps even more than those 2 GB boggled twenty years ago. Suffice it to say that if you are considering tables that will exceed MySQL’s limits, you are probably better off considering one of the truly big iron systems – Oracle or DB2. The second reason often cited is security. VFP tables are simply files on disk. If you have an ODBC driver, or the appropriate VFP-enabled application (like Word or Excel), you can open up one of those tables and cause all sorts of mayhem. A related reason is the reliability of the VFP data structure. While VFP goes to great lengths to protect the structure of the DBF file system, a table (or its related index and/or memo files) can be corrupted, causing data loss and much anguish. Database servers, because of the way they’re built and maintained, are inherently more reliable.

MySQL specifics Getting more specific, MySQL 5.0 (finally!) has all of the features you’d expect from a modern database server: size, speed, functionality.

Table sizes Depending on the operating system and file system used on the OS, MySQL will handle file sizes up to 16 terabytes for 32 bit machines and 8 million terabytes on 64 bit machines. That’s each file – not an entire database. See “1.4.4 How Large MySQL Tables Can Be” or http://dev.mysql.com/doc/refman/5.0/en/table-size.html for details.

Speed MySQL can go up against the big boys for a variety of large applications, making it perfectly suitable for the small to midsize company and sub-enterprise level applications that VFP has proved its chops at handling. DBAs like to look at the raw numbers as well as generalized claims, and you can find them on the MySQL benchmarking page here:

http://www.mysql.com/why-mysql/benchmarks/

“Big-Iron” capabilities Many people bemoaned (or denigrated) earlier versions of MySQL because it was missing this feature or that one which, while not necessarily used, were always on the ‘checkmark’ list of evaluators. Bemoan no longer – they’re here! MySQL 5.0 includes the following ‘enterprise-strength’ features:

Stored Procedures

Triggers

ACID Transactions

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 11

Views

Information Schema (meta data) tables

Distributed Transactions (across multiple databases)

and other ‘big-iron’ features, such as the ability to create a single logical database from multiple physical servers. Naturally, the MySQL people are proud of the work they’ve put into their latest version, and accordingly the MySQL web site has buckets of details on each of these features.

Business reasons

There are multiple business reasons for using MySQL, and surprisingly, they don’t all revolve around money.

Cross-platform capabilities Remember when Microsoft used to tout the cross-plat capabilities of Fox when it ran on DOS, Windows, Unix, and the Mac? And then somewhere along the line, the marketing folks got a hold of the term “cross-platform” and subverted it to mean “multiple versions of Windows”:

“Yes, VFP is cross-platform – it will run on Windows 3.1, Windows 95, AND Windows NT!” Reminds you of the “We have both kinds of music – country and western” joke from the Blues Brothers. You can develop and deploy your MySQL database on a wide variety of operating systems, including Windows, Linux, Macintosh OS X, Solaris, FreeBSD, HP-UX, IBM AIX, Novell Netware, and others. This means you’re not tied to the whims of a specific operating system manufacturer. Nor are you tied to a specific box of hardware for development or deployment – instead being able to follow the lead of Google, who relies on large farms of commodity boxes instead of expensive proprietary machines.

Installed base MySQL’s growing popularity means its installed base continues to grow, which is beneficial in a number of ways. First, more users mean more scenarios are being tested, which means a stronger product. More users mean a larger community of support. And more users mean a more attractive market for third party tools and vendors, which makes the product more flexible and able to meet unusual needs. Because of MySQL’s inexpensive licensing, more and more companies are also including it as the database engine in their products – oftentimes unbeknownst to the end user! This further grows the pool of customers.

Inexpensive MySQL’s immediate attraction to many is that it costs nothing to develop with – it can be downloaded and used for free. Deployment, while not always free, is considerably less than a similar deployment with Microsoft SQL Server or Oracle. That means if you want to kick the tires, try some things out, experiment, or even try a test deployment or three, you don’t have to shell out an arm and a leg for the complete system. Proprietary manufacturers often offer a ‘free’ version of their expensive software, but check to see if it’s truly identical to the licensed version, or if it’s crippled in some way that makes it an inappropriate choice for evaluation or testing. Compare the costs for downloading and installing a half dozen or dozen copies of MySQL for your development to the cost of development licenses for various MySQL competitors.

12

MySQL Client-Server Applications with Visual FoxPro

There are some scenarios where you’ll need to pay for MySQL licenses, typically involving deployment. But even then, the apples-to-apples comparison of license costs is far in favor of MySQL compared to the competition. When the huge cost differential is brought up, competitors ignore the real world and start talking about high-end features exclusive to their products, regardless of whether or not those features are needed.

Freedom to recompile from source MySQL’s open source license means you have access to the source code. Some folks look askance at this argument, saying they’ve never met anyone who has modified an open source package, but that’s not the point. If you are having problems with a proprietary software package, you are held hostage to their interest in helping you out. If you are having problems with an open source package, you are free to find a solution yourself – you aren’t breaking the law if you want to do so. While admittedly precious few actually go in and make changes to the source code themselves, it’s not uncommon to recompile the packages yourself in order to make them work in a special configuration. For example, suppose your environment is tied to the use of another software/hardware combination, say, via a proprietary application your business depends on, and that combination is somewhat dated or otherwise specialized. You can download the install (or even download the source and build the server application from scratch yourself) for a long list of older versions. By contrast, it may be nigh-on-to impossible to get the supported versions of a proprietary database to work on that combination of hardware and software. In fact, to attempt the same thing with proprietary software is strictly prohibited by their manufacturers. And the flexibility and freedom of open source is an advantage to your business.

Arguments against

There are always going to be those who will argue against the VFP/MySQL combination. Their reasons range from the logical (“We’re an Oracle shop and can’t afford to retrain our entire staff just to save a few bucks on licenses.”) to the political (“My boss likes Microsoft so that’s what we use, regardless of how it works.”) to the insane (“The CEO’s ex-partner owns stock in XXX, so we’re under orders never to let their stuff in our shop.”) As arguments go, the choice of computing platforms can get pretty heated, but when the smoke clears, the arguments against boil down to a few time-worn claims. Let’s take a look at those and help you deal with them.

FoxPro is dead (or obsolete, or not supported, or

)

It’s rare when a FoxPro detractor will not immediately point out Microsoft’s long time lukewarm (at best) attitude towards VFP. Nearly since the day Fox Software was bought by (or ‘merged’ with, depending on which press releases you read) Microsoft, the rumors that Microsoft was going to ‘kill’ VFP have floated around. That was in 1992. 15 years later, VFP has gone through six major releases and had close to a hundred related releases in terms of foreign language editions, service packs, and other updates. You would kinda have thought that if Microsoft really bought Fox with the intent of discontinuing it, they would have been able to get around to it by now. Witness Microsoft Bob and ActiveDocs for examples of Redmond technology that got unceremoniously dumped. It’s true that Microsoft hasn’t promoted VFP the way the VFP developer community has wanted. No argument there; I’ve been one of the loudest complainers. But there’s a big

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 13

difference between lack of promotion and lack of support. As of this writing, Microsoft has committed to supporting VFP 9.0 through 2015. Name one other Microsoft development product that has a written support plan that extends anywhere near that time span. In addition, should Microsoft, eight years hence, decide to not extend support past that time, that decision is not a signal that VFP apps will stop running the next day. Even now, in 2007, there are plenty of FoxBASE and FoxPro apps, a dozen or more years old, that continue to serve the needs they were designed for back when the Internet was merely a gleam in Al Gore’s eye and a cell phone was exclusively a business executive’s domain, not an extension of every teenager on the planet. We can be comfortable knowing that we can expect our VFP 9 applications to be running for a decade or more. After that? It’s quite possible that a rewrite will be in order – doncha think that your businesses might have changed significantly by then?

Visual FoxPro won’t have a native 64 bit version

Microsoft has stated that Visual FoxPro will remain a stand-alone, Win32 based application, and will run on 64-bit Windows in 32-bit compatibility mode. This, detractors claim, is yet another reason not to use Visual FoxPro. First of all, Microsoft also stated there was no way they would release version 7 of Internet Explorer independent of the next version of Windows. Months later, they did a 180 on that statement. They also claimed they couldn’t separate Media Player from Windows. But lo and behold, that tune has changed as well. So while this is what they’re saying now, that could change. But let’s suppose they don’t. So what? What they are saying is that VFP apps will run fine on 64-bit Windows, albeit in a different mode. What’s the problem here? Will VFP programs that are running natively on 32- bit processors run slower in a 64-bit emulator? Some folks may claim this will be the case, but until they can prove it, I remain skeptical. There are many, many FoxPro for DOS applications running in a DOS box on 32-bit Windows now – and they’re actually blindingly fast. And those systems have had a lifespan of 15 years or more. No news here, folks, move along.

ODBC is too old/slow

Once in a while I hear the “ODBC is sooooo yesterday’s-news” argument trotted out. They say that it’s too old to be useful. Alternatively, they’ll say it’s too slow. Both are bunk. ODBC is an open standard for defining access to relational databases. It is not reliant on individual database functionality or a proprietary API. All ODBC drivers support the same set of commands and functions so code that works with one is sure to work with another. This is not the case with OLEDB, which is totally reliant on native APIs – for example, the commands for the WORD provider are different from those for SQL Server! ODBC is cross platform and not reliant on any one operating system technology. OLEDB is COM based and is therefore dependent on Windows – the only OS to implement COM. Furthermore, ODBC is an international standard not controlled by any one company – though of course, any company can decide whether or not to make ODBC drivers for its products available

14

MySQL Client-Server Applications with Visual FoxPro

As far as speed

For the types of applications Visual FoxPro and MySQL will typically

be used for, ODBC speed is not going to be an issue. The MSDN article “Is ODBC the Answer?” states:

ODBC was not designed to completely replace native database APIs …. Native database APIs do a better job than ODBC of exposing the capabilities of a particular DBMS and often expose capabilities not exposed by ODBC.…

So which applications are candidates for ODBC? The best candidates are applications that work with more than one relational DBMS. This includes virtually all generic and vertical applications and some custom apps.

Only high-volume transaction processing systems should be worried about ODBC speed issues, and they are usually not built with VFP and MySQL. Finally, MySQL AB is constantly updating their driver, both to improve performance as well as deal with bugs that show up.

MySQL isn’t powerful enough

Powerful enough for what? No, you might not want to move AT&T’s 26 terabytes or FedEx’s 9 terabytes over, but who’s asking you to? The large, large majority of applications will fit in fewer than 25GB, which is certainly well within MySQL’s capabilities. Go up to the MySQL forums and nose around; you’ll find plenty of folks building systems with over ten million rows, and more than a few with 100 million rows. In some cases, they are not comparing apples and apples. MySQL detractors will use a variety of tactics, including using old versions of MySQL or ignoring capabilities of the most recent version. “MySQL doesn’t have stored procedures” is still a common refrain from many competitors. “Oh, they do? Well, they haven’t had them for long!” is about all they can respond with. Hardly a valid technical argument. In many other cases, well, let’s be frank, do you really need all the advanced features? Much like word processors, the most recent versions of all the database products are feature packed so as to meet reviewer evaluation guides – but the typical user (or developer) only uses 5% of them. Same for database servers – Microsoft, Oracle, and IBM pack their servers full of features that only 1% of their users need, but are added to satisfy those few enterprise customers. The huge majority of users use only a fraction of the available features. Do you really need clustering or the ability to distribute transaction processing across multiple databases and machines? The typical MySQL application really doesn’t.

MySQL’s ‘SQL’ is not compliant or standard

One reviewer related the situation where a group deliberated on which non-VFP database they were going to use when rewriting part of an application. The option of MySQL was brought to the table. At the time, MySQL’s chief detractor at the table, a developer with SQL certification from Microsoft, argued that one important reason not to choose MySQL was that MySQL’s ‘SQL’ is not as ANSI 92/99 compliant or as standard as Microsoft’s SQL. This developer claimed that if you opted to use MySQL from the outset and eventually decided you wanted or needed to up-size to a commercial alternative you would more than likely be rewriting your

Chapter 1: Why Client-Server? Why VFP? Why MySQL? 15

queries, stored procedures, and triggers because the SQL syntax would be broken in a DBMS like Microsoft SQL. MySQL has the following to say regarding the issue of standards compliance, at

http://dev.mysql.com/doc/refman/5.0/en/compatibility.html

“One of our main goals with the product is to continue to work toward compliance with the SQL standard, but without sacrificing speed or reliability. We are not afraid to add extensions to SQL or support for non-SQL features if this greatly increases the usability of MySQL Server for a large segment of our user base.” Admittedly, there are features in MySQL that go beyond ANSI standards. These features and the functionality they provide would assuredly be broken if that code were run under Microsoft SQL, Oracle, or any other database. However, if this is a serious concern to you (how many folks move from one back-end to another without spending significant amounts of time reworking the application itself as well?), you can avail yourself of MySQL without permitting yourself to use features or syntax that fall outside the standard. The mysqld command used to start MySQL has --ansi and --sql-mode options that force the user to “Use standard (ANSI) SQL syntax instead of MySQL syntax”, as per the documentation here:

http://dev.mysql.com/doc/refman/5.0/en/server-options.html

Finally, you can still write code that is more easily ported to another back-end via appropriate documentation, says their documentation at:

MySQL Server supports some extensions that you probably won’t find in other SQL DBMSs. Be warned that if you use them, your code won’t be portable to other SQL servers. In some cases, you can write code that includes MySQL extensions, but is still portable, by using comments of the following form:

/*! MySQL-specific code */"

Finally, every version of SQL has their own proprietary, non-standard extensions. The three major DBMS vendors, IBM, Microsoft, and Oracle, all seem to offer features and syntax variations beyond standard and the idea of true portability seems largely fantasy to begin with. See Peter Gulutzan’s article here:

http://www.dbazine.com/db2/db2-disarticles/gulutzan3

You’ll see that claiming MySQL is not as compliant as another database is a straw man – they’re faulting MySQL for something they themselves do just as well. It is obvious that maintaining portable MySQL syntax requires forethought and discipline, but this goal is certainly achievable. I would argue that the entire objection probably has relevance in a small minority of cases.

Conclusion/Summary

The combination of Visual FoxPro and MySQL offers a powerful, easy-to-use, fast development tool set for building a large percentage of client-server applications needed

16

MySQL Client-Server Applications with Visual FoxPro

today, with extremely cost-effective licensing that means fewer dollars out of your, or your customer’s, pockets.

Updates and corrections to this chapter can be found on Hentzenwerke’s Web site, www.hentzenwerke.com. Click “Catalog” and navigate to the page for this book.

Chapter 2: Development and Deployment Scenarios 17

Chapter 2 Development and Deployment Scenarios

Given that MySQL is a true cross-platform database that runs on Windows, Linux, and Macintosh (as well as others), there are many combinations of environments in which VFP works with MySQL. Together with the segregated requirements of client-server components and the disparate needs of a VFP/MySQL developer during development, testing, and deployment, it can be confusing to understand what pieces are required and where they fit. This chapter discusses the various scenarios, what the components for each combination are, and how they fit together.

The configuration of simple Visual FoxPro applications is fairly easy to understand – an EXE, some run-time files, and a few DBFs. But client-server applications using VFP and MySQL are more complex. While I’ll go into detail about installation on Windows and on Linux in Chapters 3 and 4, it can be helpful to get a birds-eye view of how the various pieces fit together before going into that detail. Let’s take a look at the big picture first.

The big picture of how pieces fit together

In brief, for your development configuration, you:

1. Install Visual FoxPro on a Windows box,

2. Install the MySQL ODBC driver on the same Windows box,

3. Install the MySQL engine either on the same Windows box or a separate box (running

Windows, Linux, Macintosh, or another OS), and

4. Put the database on the same box as the MySQL engine.

If the MySQL engine is on a separate box from VFP, all that is required is for the box to be reachable by the Windows box via a TCP/IP connection. Now that the pieces are in place, you connect to MySQL from VFP through the ODBC driver. Once connected, you can use remote views, SQL pass-through, or cursor adapters to bring selected data into your application, work with that data for a while, and then stuff it back into the database. After you’ve developed, tested, and staged your application (I know, this sounds like one of those “Step 3. Then a miracle occurs” jokes), you deploy the end result to production. In production, the MySQL engine will reside on the ultimate server box (again, running Windows, Linux, Mac, or another OS). The production database will also reside on the server box. Your VFP executable, VFP run-time files, and the MySQL ODBC driver will be installed on the client (end-user) Windows boxes.

The components

There are three groups of components that we’re dealing with: Visual FoxPro, the ODBC driver to connect to the MySQL database, and MySQL.

18

MySQL Client-Server Applications with Visual FoxPro

Visual FoxPro

As development environments go, the VFP architecture and installation requirements are rather straightforward. With the exception of a couple of runtime DLLs that go into the Program Files\Common Files\Microsoft Shared\VFP directory, the entire installation ends up in Program Files\Microsoft Visual FoxPro 9 directory by default. VFP installs off of the CD. The VFP IDE is shown in Figure 1.

installs off of the CD. The VFP IDE is shown in Figure 1 . Figure 1

Figure 1. The Visual FoxPro IDE with the Command Window, Data Session, and two debugging windows.

The IDE provides access to the programming language via the menu and the Command Window, as well as all of the visual tools, such as the Form Designer and Report Writer, and the development tools, like the Object Browser and Debugger. Once installed, you can customize VFP’s behavior through the Tools | Options menu, but no specific configuration is required to use VFP with MySQL. There are three ways to use VFP to connect to MySQL (all using the ODBC driver). These are (1) remote views, (2) SQL Pass-through, and (3) CursorAdaptors. You don’t have to do anything additional, or install any other software, in order to use any of these mechanisms.

Chapter 2: Development and Deployment Scenarios 19

ODBC driver

ODBC (Open Database Connectivity) is a standard database access method developed over a decade ago and in widespread use even today. The goal of ODBC was to provide a bridge between data and applications, using an intermediary called an ODBC driver. It is the link between Visual FoxPro and MySQL, regardless of whether they are on the same machine or on boxes separated by half the planet. You can set up connections to different databases and switch between the databases simply by changing the connection your application uses. The MySQL ODBC driver is a standard ODBC driver, consisting of a DLL and a LIB file that both end up in the Windows\System32 directory. Once installed, you’ll find it in the Drivers tab of the ODBC Data Source Administrator as shown in Figure 2. (To find it, select Start | Settings | Control Panel | Administrator tools | Data Sources (ODBC) in Windows 2000, or Start | Settings | Control Panel | Performance and Maintenance | Administrator Tools | Data Sources (ODBC) in Windows XP.) I’ll cover installation and configuration of the ODBC driver in Chapter 6.

and configuration of the ODBC driver in Chapter 6. Figure 2 . The ODBC Drivers page

Figure 2. The ODBC Drivers page with the MySQL ODBC driver highlighted.

MySQL

Let’s not beat around the bushes – there are a lot of parts to MySQL. To understand them, it’s helpful to know how MySQL itself works, in a general way. MySQL is a software application that runs as a service (known as a ‘daemon’ in Linux parlance) on a computer. This means that once it’s installed and started, it waits in the background for a request and returns the result of attempting to carry out the requested action. This could be a value, a result set, or an error message. Similar to the way a Web server takes requests from a browser and delivers Web pages back to the browser, the MySQL server takes requests from a user, queries or modifies the database as a response to those requests, and finally returns those results to the user. The server is just a program (either ‘mysql.exe’ on Windows or ‘mysqld’ on Linux) that can be started up automatically when the machine is booted, or manually by issuing a

20

MySQL Client-Server Applications with Visual FoxPro

command in a command window. During startup, it looks for information about how to

configure itself from a configuration file. It creates a socket file (provides an anchor for a connection) and a PID file (a placeholder that identifies which instance of MySQL is connected to the databases, as a machine can run multiple instances of MySQL). Once running, it waits in the background for requests from users and performs them on databases in a predefined location. The software that supports these functions can be grouped into five general categories:

1. Database engine

2. Database files

3. Client tools

4. GUI tools

5. Scripts

First is the MySQL database engine itself. On Windows, it’s mysql.exe, located in the \bin directory under wherever you install MySQL – either \Program Files on Windows or on Linux, it’s /usr/var/mysql/mysqld. (Executable files on Linux don’t necessarily have extensions.) Next are the database files. You can determine where they are located during installation. Unlike VFP, MySQL has several different types of storage engines, including the MySQL ISAM type and the InnoDB type. The number and types of files vary according to what type of storage engine you choose. Third are the client tools. These allow command line access to the database engine, somewhat similar to the way you can use commands to access and manipulate Fox data. Fourth are the GUI tools. These, similar to the client tools, allow access to the database engine, but via graphical interfaces. These tools include the MySQL Administrator, the Query Browser, and the Data Converter. Their locations can be chosen during installation, although I typically put them in directories off of the mysql installation, such as c:\mysql\bin\admin and c:\mysql\bin\qb on Windows, and similar paths on Linux. Finally, we have the scripts (Windows users – think ‘batch files’). These scripts are installed along with the MySQL database engine installation and perform tasks like creating privilege tables, setting permissions, converting tables to ISAM format, securing an installation, and performing a hot backup of a production MySQL database.

The scenarios

I recently spent some time with my 8th grader going over combination problems in her math class. You know the type – “Jack has four pairs of pants and six shirts – how many days can he wear a different combination?” The same type of math generates a very large number when applied to the various permutations of VFP and MySQL on various operating systems and machines. Instead of trying to go through each of them, I’ll approach the problem a different way. I’ll cover development scenarios first, including testing requirements, and then revisit them in terms of what’s different for production.

Development

VFP First, you’re a software developer. You have a machine that’s running Visual FoxPro. While you can technically run VFP on Linux (via WINE or Crossover Office), that’s not a common

Chapter 2: Development and Deployment Scenarios 21

option, so I’ll assume this box is running Windows – either Windows 2000, Windows XP, or Windows 2003, as Windows Vista was just barely released during this writing. Second, you have the MySQL ODBC driver installed on that Windows machine. And now it gets interesting – you have multiple choices for where MySQL is located. There are several good reasons to put the engine itself on the same machine as the development environment, and other good reasons to put the engine on a different box. I’ll cover the pros and cons for each in the appropriate section.

MySQL on the local Windows machine Choice number one is to install MySQL on the Windows box as well.

I prefer to run the engine on the local box for the simple reason of expediency. Response

is faster – while network connections are fast, being on the same box is virtually immediate. As I heard a long, long time ago, the key to successful iterative development is to keep the

iteration turnover shorter than your attention span. And as one gets older, one’s attention span gets shorter, so every trick in the book to speed up that iteration time helps. Second, my development becomes portable. I personally develop on a notebook, but even if you use a desktop or other semi-luggable box, being able to pick up and move your entire development environment can come in handy, either because you must (power failure, water pipe explosion overhead, office closure, whatever) or because you want to (going to the cottage for the weekend, heading over to the library or coffee shop to meet an associate, whatever). If your development back end is on another box, either you have to rely on a network connection wherever you’re going, or deal with tearing down, moving, and setting up two boxes. It may not be a big deal to you, but to me, it’s time that I could spend doing other things. Second, relying on a second box adds at least two more points of failure – the network connection itself as well as the other box. When I’m developing, failures cost money. Putting more potential points of failure in the development process is unnecessarily risky. Third, incorporating a network connection adds additional complexity to the environment. It may not be a LOT of complexity, but it’s still there. And having to deal with the troubles that additional complexity can bring during heads-down development is an unnecessary distraction. Note that installing MySQL on your local box does not absolve you of having to set it up on a separate box for testing! If you choose the single machine installation route, after installing VFP and the MySQL ODBC driver on your local box, you’ll also install the MySQL server and client packages, and then whichever of the MySQL GUI tools that you want. I’d suggest both the Administrator and the Query Browser, as they don’t take up a lot of space and are pretty handy, particularly for folks who are used to GUI tools. Scripts will get installed along with the server and client packages automatically. During the installation of the server, you’ll be asked where you want to put the MySQL database files – in other words, your application’s data. The default on Windows is under the MySQL software tree, which to my way of thinking isn’t a great idea – your data never belongs on drive C, nor in the software’s installation tree.

22

MySQL Client-Server Applications with Visual FoxPro

Some will argue that doing all of your development on a local machine can give you a false sense of security in terms of how fast your application is – you spend months developing locally, and then you roll it out for a customer to see and suddenly find out where the bottlenecks are. It can be embarrassing. My answer to this scenario is that I always have testing done with a remote server. A testing environment is much more like production will be than what my development environment will be. And the test folks are plenty willing to provide feedback on how the system performs.

MySQL on a remote machine The other choice is to put MySQL on a second (“remote”) box. There are a number of good reasons to have your MySQL installation on a separate box – and it doesn’t really matter what the OS is running on the second box. First of all, you’re going to have to connect to a second box from a client at some point, because your application will need to do so in production. No one wants to be the fellow who

shrugs in front of the customer, saying, “Well, it worked on my machine

Second, you don’t want to try to do your first-ever remote connection the night before “The Big Install.” By setting up a separate box early in the game, you’ll have the luxury of debugging problems without the spectre of time running out looming over your head. Just as you don’t want to be the “Worked on My Machine” guy, you don’t want to be the guy who is up till 4:30 am the morning of the “Big Delivery To The Customer,” trying to puzzle out why your system won’t connect via panicked emails to a mailing list where the only folks on-line are a) folks in a time-zone 12 hours away, with the attendant possible language differences, or b) similarly panicked folks like you, who won’t be of much help. Third, once your remote box is set up, you can emulate your customer’s environment more closely, and that’s always a good thing. You’ll be able to test more accurately, and it makes troubleshooting easier and more reliable. Also, you can verify that your network’s speed can handle the traffic your application will add. Properly done, you can even do load testing to make sure your application can handle as many users as will be necessary. Additionally, since you’re going to have a second box, you might as well set it up and then put it in the server room, the basement, the attic – wherever it’s a little bit inconvenient to have to physically get in front of it. Thus, you’ll be forced to learn how to administer the box remotely as well. While your current gig might not require you to develop this level of knowledge, who’s to say your next one won’t? And it’s not unheard of to have a customer swear up and down that they will take care of the administration once it’s installed, but the next time you visit, their DBA is “unavailable” (that’s French for ‘too busy’, ‘sick’, or ‘fired’) and “could you just take a look at one thing?” You become the hero if you have the capability to get into their system as a remote administrator. Finally, there’s also the advantage of security. A client’s data may contain sensitive information: names, SSN’s, birthdates, medical information, and operational information. If the data is on your laptop, it’s subject to theft with that oh-so-portable laptop of yours. If it’s locked up tight on a server behind a firewall with secure access, strong passwords, and good security processes, it’s less likely to get pinched when you step away just for a second to refill that latte grande. This entire discussion so far has been based on the assumption that you’re the only developer working on the system. If you have more than one developer working on the

Chapter 2: Development and Deployment Scenarios 23

application that needs the database, the choice becomes moot. You’ll need to put the database on a server that everyone can access. And since you’re likely not going to want others connecting to your own development box to access your local database server, the logical choice for the database is a second box. Expanding on this last point, you can also easily poke a hole in your firewall (say, limited to one IP address) to allow your customer to access the remote database, say, for demonstration or testing purposes. You probably wouldn’t want to do that with your local development box. Finally, it is entirely plausible that you will be involved in using a MySQL database hosted on an ISP’s site. In that scenario, you will definitely need to be able to do administration remotely. The entire preceding argument has sort of danced around the question of whether you use the remote box for your day-to-day development. Some people swear by the use of a second box for their day-to-day work, and there’s a valid argument here – the more hours you spend working with a remote box, the more experience you’ll get, and in the long run, that experience will be good for you. If you choose that route, the $64,000 question becomes “OK, what goes where with a remote box?” This explanation actually works with all flavors of a remote box – Windows, Linux, Mac, etc. You’ll install the MySQL server (the ‘engine’) and client tools on the remote box. Doing so will also create the scripts as well as the database on the remote box. The GUI tools are designed to be used when you’re physically in front of the machine, so you don’t need to install them on the remote machine at all. Sure, you could, if you wanted to use GUI tools to administer the remote box during those times when you’re not connecting to it remotely, but, rather, sitting right in front of it. But after you get the remote box running (using the MySQL monitor, which is part of the client package), you’re likely to put it in a closet, take the head off (that means remove the monitor, mouse, and keyboard – a common scenario for Linux servers), and not touch it again until the cooling fan or hard drive smokes. Then all of your future administration will be handled from another machine. “But I LIKE the GUI tools,” you whine. Never fear. So do I. You can still use GUI tools on one box (say, your development box) to access the database server on the remote machine. Some would argue that having the GUI tools installed on the server used for development can be a good thing, in order to troubleshoot locally with the tools you’re familiar with. Maybe the server isn’t responding to remote access. Or features and functionality seem to be missing. Having to figure it out from a remote command line can be a nuisance. I personally don’t go this route, but it’s more of a personal preference than an absolute.

Production

Production is a different beast than development, in the same way that the country club where your daughter is getting married is different than the family room that opens up onto the deck in your backyard. Well, at least for me. The production machine is clean and orderly, with no ‘half-finished’ projects lying around, while the development machine is always in a state of mild disrepair. Still, the same separation of function basically applies – you’ll have client machines running the Visual FoxPro application, and a separate server machine running MySQL and holding the database.

24

MySQL Client-Server Applications with Visual FoxPro

Client machines On your development machine, you’ll build an executable (.EXE) file from Visual FoxPro that contains all of the functionality the user wants in your system. You’ll install that EXE, along with Visual FoxPro runtime files and the MySQL ODBC driver, on each client machine. For all but perhaps the simplest of applications, you’ll use an installation tool like InstallShield or InnoSetup to handle all of the plumbing – registering DLLs, configuring components, and installing all the pieces that tend to get left behind if done manually. Some folks also put together an automatic updating utility (written in VFP, of course) that allows the developer to centrally manage the deployment of updates. You won’t install the Visual FoxPro development environment, nor will you install any of the administration or GUI tools for MySQL, unless you’re expecting to have to use one of your client workstations for that purpose. This means you don’t need to buy any sort of license or pay royalties for the clients – which can mean considerable savings over software like Microsoft SQL Server that requires client access licenses for each user.

Server machine The server machine will hold the MySQL server application and the database files. Thus, you’ll perform the server and client software installations on the server machine, which in turn will take care of the database creation for you. You’ll need to configure the server for your particular needs and deploy your applications database yourself, unless you’ve put together an automated installation routine that does it for you. As with client machines, the details to create such an automated routine are beyond the scope of this book.

Conclusion/Summary

All things considered, if having your MySQL on a remote machine similar to your production server is not a major inconvenience, and doesn’t pose an unreasonable barrier to speedy day- to-day development, I recommend doing so for all the practice you will have with the remote environment and the realistic response. It is important to have experience with a remote server so you don’t get lulled into a false perception of performance for the application. At the same time, you don’t want to unnecessarily handicap yourself during development when performance can be tested at the appropriate time.

Updates and corrections to this chapter can be found on Hentzenwerke’s Web site, www.hentzenwerke.com. Click “Catalog” and navigate to the page for this book.

Chapter 3: Installing MySQL on Windows 25

Chapter 3 Installing MySQL on Windows

Installation is like finding the emergency brake in your car. Once you know where it is, it seems rather trivial. However, if you can’t find it, you’re not going very far. In this chapter, I’ll show you how to install MySQL on a Windows box, starting with downloading the right files, and finishing up with some troubleshooting steps. In subsequent chapters, I’ll describe the connection process between MySQL and VFP.

This chapter covers the installation of the MySQL server on a single computer running Windows. There are several ways to install MySQL. You can either install it via a standard Windows installer, much like you install most other Windows programs, or you can build the executable files yourself from source. This chapter describes how to use the installer, and then configure MySQL once installed. Note that throughout this chapter, I’ve included screen shots of the MySQL website. It is highly likely that the site will see modifications that render some, if not all, of these images out of date. However, I’ve found over the years that the essential items you’re looking for keep the same names – they’re just in somewhat different locations.

Software and environment

This chapter was written using MySQL 5.0.18 and Windows 2000 with the latest service packs installed, but I’ve used these same steps, with minor differences (such as version numbers of the downloaded MySQL files) to install other combinations, all the way back to MySQL 3.23. When appropriate, I will mention the differences between Windows 2000 and Windows XP. In the examples used in this chapter, the Windows box is named ‘example’, with an IP address of 192.168.1.7 and a day-to-day user named ‘whil’. The user account in MySQL will be named ‘bob’. (This Windows box is also running Visual FoxPro, but in Chapter 5, “User Configuration,” I’ll address the concepts for communicating with a remote Windows box.)

The big picture – what installation does

If you haven’t already, read Chapter 2 on how MySQL works to make sure you understand the context. MySQL on Windows consists, in a general sense, of two sets of files – the server and the client. The server installation process installs the MySQL server – the actual software application. The Windows version of the MySQL server application itself is mysqld.exe, located in a directory of your choosing, such as c:\Program Files\MySQL Server

5.0\MySQL\bin\mysqld.exe.

The client installation puts a number of client programs and scripts (think ‘batch files’) in directories on the same level as the ‘\bin’ directory under ‘mysql’, wherever you decided to put it. Then the installation process sets up the server as a service, enables the service to be started automatically upon boot-up, creates user accounts and data files, and turns over the keys to you.

26

MySQL Client-Server Applications with Visual FoxPro

The essential installation process

Installation of MySQL involves five steps:

(1) Read the documentation on the MySQL site, (2) Download the appropriate file(s), (3) Run the installer, (4) Test the installation, and (5) Configure users and set passwords. Because the user configuration and password setting process is the same for both Windows and Linux, I’ve given it its own chapter following Chapter 4, “Installing MySQL on Linux.”

Read the documentation

Since you’re reading this document, you’re not too adverse to reading the fine manual that comes with the product, and in this specific case, I urge you to take advantage of it. The online documentation is very good, and you shouldn’t take this document as a substitute for it. However, the documentation has to cover all possible scenarios, such as installing various types of files (RPMs and tar files) on Windows, Linux, and other operating systems, so it can be confusing when having to skip parts that are not related to your particular situation. Thus, I winnowed out the parts not relevant to this particular type of installation, but point you to specific sections in the documentation when the time comes. So look at this document as a supplement to the online documentation, not a replacement. The MySQL folks continually change the interface of the www.mysql.com website, and so it’s impossible to provide specific steps that will work for finding the documentation regardless of what year you’re reading this. Either go to http://www.mysql.com and look for “Developers” or “Community” links, or go to http://dev.mysql.com (hopefully this URL won’t change for a while) and look for a link for Documentation. I found the documentation to the right of the “HTML, viewable online” links (separate versions for the different releases of MySQL) to be easy to navigate and very useful, as the user comments that are often added at the end of many sections provide additional tips and a variety of perspectives of real life usage. Consider adding a direct link to the online documentation as a bookmark in your favorite browser.

Download files

Before you actually download the MySQL installation files, you should decide where to put them.

Decide on a target location

Personally, I put all of the files I download into a directory called “zips” on my file server. Once I find that I’m actually using a program or tool, I’ll archive the installation file(s) to the server for backup. It can be awfully inconvenient to want to reinstall something and find out that you can’t get to the vendor’s website. Also, if you’re using Firefox and have the downloading window turned off, you can temporarily turn it back on via Tools | Downloads, as shown in Figure 1.

Chapter 3: Installing MySQL on Windows 27

Chapter 3: Installing MySQL on Windows 27 Figure 1 . Opening the Downloads window in Firefox.

Figure 1. Opening the Downloads window in Firefox.

Doing so will open the download window, as shown in Figure 2.

so will open the download window, as shown in Figure 2 . Figure 2 . A

Figure 2. A sample Downloads window in Firefox.

Grab the files

Once you decide on your own storage location, it’s time to find the files. Like the documentation, the links tend to move around over time. There are two general versions, the Enterprise Server and the Community Server. Further complicating the matter is that at any given time, there are multiple versions of both – older versions (3.x, 4.x), the current stable

28

MySQL Client-Server Applications with Visual FoxPro

version (often referred to as the Generally Available Release), and one or more alpha and beta releases. For the purposes of this book, you’re looking for the Generally Available (GA) Community version. Navigate to http://dev.mysql.com, click on Downloads, and look for a reference to the Community Server. Scroll down to the link for Windows, click on it, and you’ll see a list of Windows-related files as shown in Figure 3.

see a list of Windows-related files as shown in Figure 3 . Figure 3 . Navigating

Figure 3. Navigating to the Windows downloads for the MySQL engine.

You’ll see links to three possible choices:

Windows Essentials (about 17 MB)

Windows (x86) (about 33 MB)

Without installer (unzip in C:\) (about 35 MB)

Select the middle link – Windows (x86) – that contains the complete package of files. If you’re short on disk space, the Essentials download contains the minimum set of files needed to install MySQL on Windows, including the Configuration Wizard. Before you actually grab the file itself, I suggest you cut and paste the MD5 text string from this page and pop it into an empty text file editor window; you’ll use this in a few moments. Click on the ‘Pick a mirro