Monday, November 26, 2018

My Advice: Monitor Your Health

Permit me to share a bit of unsolicited advice. There are two parts to it. First, get an annual physical from a health professional. Second, if you sense an unusual change in your health, seek a physician’s advice.

Getting an annual checkup, with the accompanying tests (physical examination, blood work) permits you to establish baseline measurements about your health, which can be useful in identifying trends that may require additional follow-up. Seeking help when you experience an unexpected change (increased pain, odd swelling, etc.) can potentially identify a problem while it is still in an early stage.

I give this advice because I have seen family and friends skip annual checkups (“I’m very healthy. I don’t need to see a doctor” or “I hate going to the doctor”), or ignore warning signs. In one heartbreaking case for me, this lead to the untimely, and completely avoidable death of a wonderful individual, depriving us all, permanently, of the joy of their presence.

Consider my situation. I get annual checkups, and during a recent examination my PSA (prostate specific antigen) blood test showed an increase in PSA. A subsequent test confirmed this, and I had a biopsy to determine the cause. It was cancer. Due to the type of cancer, and my age, I had two options: Radiation and surgery. I opted for surgery, and the operation was performed at the end of February this year.

Based on the post-surgical lab work on the removed tissue, and the first three post-op PSA tests, it looked like I was cancer-free. This changed earlier this month, as I now have a detectable PSA reading, which means that the cancer is still present. Importantly, we reacted quickly to the original diagnosis, and we are moving aggressively to address this new information. By doing so, we are giving me to best opportunity to overcome this ailment.

I’m sharing my story, and offering my advice, in hope that you monitor your health, providing you with the opportunity to address and overcome any obstacles before they get out of control, to the benefit of you and your loved ones.

So, please, if at all possible, adopt a regime of annual physicals. And if you notice something wrong, or out of the ordinary, get it checked out.

Thursday, October 4, 2018

Cary Jensen is available to help your Delphi team

Are you looking for help with your Delphi applications and/or your Delphi team? I will be available for contract work starting in mid-November 2018.

Over the past 30 years, I have primarily been a software developer specializing in database applications, but I am also the author of more than 25 books on software, and have written over 100 courses on software development. I was the author of, and principle trainer on the original Delphi World Tour in 1995, continuing until it concluded in 1999. On a related note, I am the founder of Delphi Developer Days, which began in 2001 and continues to this day.

On the more technical level, I have a Ph.D. in Engineering Psychology, specializing in human/computer interaction. My studies emphasized an analytical approach, with a heavy dose of statistics.

Due to my commitments to writing, Delphi Developer Days, and existing clients, I am looking for a part-time opportunity, where I can provide from one to three weeks of support each month.

I love to travel, so I am particularly interested in opportunities that include onsite work almost anywhere in the world, but I am open to some remote support.

I can help in the following areas:
• Application architecture
• Object-oriented development
• Legacy application migration to recent versions of Delphi
• Application refactoring to improve maintenance and support
• Class and component creation
• Evaluating employee candidates
• Developer training
• Developer mentoring
• Class and component creation
• Software documentation
• General business consulting

If you are interested in learning more about how I can help your organization, please contact me at the following email address: cary at

Monday, September 3, 2018

Sign Up for the Delphi Community Edition Boot Camp Today

If you are new to Delphi, the cross-platform, native compiling rapid application development (RAD) tool from Embarcadero Technologies, or know someone who is, there’s an upcoming event that you need to know about. It is the Delphi Community Edition (CE) Boot Camp.

The Delphi CE Boot Camp is a series of lectures designed to introduce you to developing world-class applications using Delphi. Beginning on September 3rd, and continuing for a total of 8 weeks, each week introduces you to a different aspect of Delphi development, from building the user interface to compiling applications for iOS and Android devices. Week 1 begins with an introduction to the Delphi language (object-oriented Pascal), presented by Delphi guru and Delphi Product Manager Marco Cant├║.

The Delphi CE Boot Camp is free for everyone. To attend, use the following link to get started:

The lessons for each week will become available on the date listed for each topic area. You can watch the lessons any time you want once they are published. In addition, some lessons are followed up with live question and answer sessions with the instructor. See the Boot Camp site for details.

Don’t have a current copy of Delphi. No problem. So long as you meet the requirements, you can download and use the free Delphi Community Edition which became available this past July. The Delphi Community Edition is a full featured Professional Edition designed to get you up and running. To learn more about the Delphi Community Edition, along with its terms of use, visit

If you are a database developer, you will want to attend my course on database development with Delphi. My lessons will become available on September 24th.

If you have colleagues who are new to Delphi, please be sure to share this information with them. There’s never been a better time to get started with the best native compiler for building applications for Windows, OSX, iOS, Android, and Linux.

Tuesday, June 13, 2017

Announcing Delphi Developer Days 2017 Special Edition Database Workshop

I am pleased to announce that registration is now open for Delphi Developer Days 2017 Special Edition Database Workshop with Bob Swart and me, Cary Jensen, which will be held this fall in the U.S. and Europe.

Unlike our traditional Delphi Developer Days events, which include a broad range of topics, this workshop focuses exclusively on database development. It begins with a detailed look at connecting to data and configuring FireDAC, and continues with a look at some of FireDAC’s more advanced features, including Array DML, the SQL command preprocessor, and cached updates.

The workshop continues with an in-depth discussion of multi-tier development. Topics include creating DataSnap servers and using Embarcadero’s RAD Server. Here you will learn how to access your data from mobile applications, how to support both Delphi and non-Delphi clients using REST (REpresentational State Transfer), and how to create RAD Server microservices with Delphi.

Both days of this workshop are taught jointly by me and Bob. You are encouraged (though not required) to bring a laptop in order to follow along with the provided code samples.

Each attendee will receive a Delphi Developer Days course book, which includes a special edition of my latest book Delphi in Depth: FireDAC, along with material on DataSnap, mobile development, and RAD Server written by Bob (Dr.Bob) Swart.

Here are the cities and dates for this fall tour:
Chicago, 25-26 September 2017
Antwerp, Belgium, 9-10 October 2017
Frankfurt, Germany, 27-28 November 2017

In addition to the course book, attendees also receive lunch on each day and all code samples covered during the workshop. Due to the nature of this workshop format, seating is limited. Register now to save your place in this special edition database workshop and receive a substantial discount for early registration. For more information, visit

The Delphi Developer Days 2017 Special Edition Database Workshop is taught in English.

Note that we will return with the traditional Delphi Developer Days event in the spring of 2018, where we present both joint as well as separate sessions on a wide variety of Delphi topics.

Friday, May 12, 2017

Delphi in Depth: FireDAC is now available

Last autumn, as I was finishing up my chapters for the 2016 Delphi Developer Days course book, which I wrote with Nick Hodges, Director of Engineering at Embarcadero Technologies, I received a question about FireDAC from my German colleague Dr. Holger Flick. He was asking about the relevance of my ClientDataSet book to some work he was doing with FireDAC. I replied that the book would help to some extent since so many aspects of Delphi database development were covered by that book, and that I had used FireDAC and InterBase for many of that book’s examples.

But his question got me to thinking about the FireDAC material that I had already written. I had four or five chapters from previous Delphi Developer Days, I had another three or four articles that I had published in software-related magazines, and I had several FireDAC presentations from CodeRage under my belt. I might have half a book there already. Why not, I thought, my next book will be a FireDAC book.

I don’t regret that decision at all, though I must say that even I was surprised at how much work it was to complete this book. This is my twenty-sixth book (and that’s not counting the eight Delphi Developer Days books that we’ve published since 2009). I know how much work it takes to write a book, but this one was different. The amount of research that this book required was a surprise.

For one thing, I felt that this book should be more than just a FireDAC book. It should be a book that deserves to be on the shelf of every Delphi database developer. For the new Delphi database developer who is unfamiliar with the “Delphi way” of doing things, this book contains discussions of and demonstrations of the essential techniques that every Delphi database developer needs to know. This includes concepts like the TDataSet interface, the current record, and how to read to and write from TFields. (Just a note here, this book assumes you are using Delphi XE6 or later.)

The advanced Delphi database developer, however, is not left out. These developers may simply want to scan some of the chapters where core concepts are reviewed, but there are many chapters that delve into some of the more powerful and exciting features of FireDAC, including virtual field management, cloned cursors, and cached updates.

So, the short story is that the book was a lot of work, and in the end, worth the effort.
The book begins with an overview of FireDAC, including its features and benefits. In chapter 2 you learn the many different ways to connect to your data, whether you are using one of the mainstream databases and a FireDAC native driver or are migrating from a legacy file-server database.

Chapter 3 explores how you configure FireDAC to control nearly every aspect of your data retrieval, in-memory management, and subsequent database writes. Here you learn about FireDAC dataset property inheritance, and how to fine tune configurations at the individual component level.

Chapters 4 and 5 demonstrate how you communicate with the underlying database using dataset components, queries, and stored procedures. Here I describe the capabilities of these components, as well as some of their basic configuration, including how to create and use parameterized query and stored procedure calls. I also cover how to use transactions, as well as how to monitor the database connections from your running applications.

Chapter 6 introduces the fundamentals of Delphi database development, introducing concepts like the current record, data-bound navigation and editing, as well as programmatic navigation and editing. Chapter 7 introduces the creation and use of indexes, while chapters 8 and 9 discuss searches and filtering, many techniques of which employee indexes.

These four chapters are specifically intended to provide a core understanding of data-related operations in Delphi. I expect the more advanced Delphi database developers to quickly scan chapter 6 for anything that doesn’t look familiar. However, even the advanced developer may glean new and useful information from a more thorough read of chapters 7 through 9, as several of the technical reviewers noted (and these guys are definitely advanced Delphi database developers).

The remaining chapters of this book are dedicated to more advanced FireDAC technologies that can enable sophisticated solutions in your database applications. Chapter 10 introduces virtual fields, and shows you how to use aggregates, Calculated (and InternalCalc) fields, and Lookup fields. It also examines the FieldsOptions property, a feature introduced in Delphi XE6.

In chapter 11 I cover how to persist your FireDAC datasets and FDSchemaAdapters to files and streams, as well as how to retrieve that data. There’s a lot of good stuff in that chapter, including how to control what data is persisted, and how data being loaded can interact with data that is already loaded.

In Chapter 12 and 13 I explore the FDMemTable. Here I discuss the role played by the FDMemTable within the FireDAC landscape, and then examine many of the techniques that are best suited for FDMemTables. Topics include the dynamic creation of FDMemTable structure, loading FDMemTables from other datasets, cloning cursors, and creating nested datasets.

In Chapter 14 I take an in-depth look at the SQL command preprocessor. Here you learn how to add tremendous flexibility to your SQL statements, features that permit you to run a common set of SQL statements across two or more different database servers. The SQL command preprocessor also gives you unprecedented control over expressions that you add to your SQL, introducing dozens of FireDAC scalar functions for your use.

Chapter 15 covers Array DML (Data Manipulation Language), a high-speed mechanism for executing a large number of similar parameterized queries, for instance, when you are inserting thousands of records into a given table with an INSERT SQL statement. When you need to update or insert a large amount of data quickly, this is your tool.

In Chapter 16 I examine a feature that I have been a champion of for years, cached updates. Here you will learn how to create, manage, and exploit cached updates to create advanced features for your applications. I also discuss both the decentralized and centralized models of cached updates, and provide important guidance for the process of applying updates and handling potential update failures.

I finish the book with a short chapter on Local SQL, demonstrating how to configure your FireDAC components to perform SQL queries on any Delphi dataset or combination of datasets. It’s a powerful technique that provides for solutions that would previously be difficult or impossible.

This has been a challenging while fun and rewarding project for me, and for those of you who buy my book, thank you! I hope you enjoy it.

Still interested? Learn more here:

Monday, November 7, 2016

A Special Year for Delphi Developer Days

Delphi Developer Days 2016 with Nick Hodges and me, Cary Jensen, is just around the corner (we start in Chicago a week from today). And, the Delphi Developer Days book has been printed, which for an author is that one milestone that is always rewarding. As in years past, this book is once again weighing in at about 400 pages.

This year is very special for another reason. We started planning Delphi Developer Days 2016 back in late May, and this year I have the pleasure of working with my longtime friend and former Delphi Product Manager Nick Hodges.

Nick has been a prolific writer over the past couple of years, publishing not one, but two Delphi books (Coding in Delphi and More Coding in Delphi). I was really looking forward to working with him on the Delphi Developer Days book, and I was not let down one bit. This book is loaded with good stuff, and I cannot wait for our chance to present this material.

But that is not the special part I am talking about. My past Delphi Developer Days presenters have all been serious contributors to the Delphi community. Marco Cant├╣ has gone on to become the current Delphi Product Manager. Bob Swart continues to speak at conferences, publish articles, and runs the Delphi Developer Network in the Netherlands (and I look forward to his return to Delphi Developer Days as my co-presenter next year). Ray Konopka continues his great work, and both Konopka Signature Components and Code Site are bundled with various versions of Delphi. And then, in September, we learned that Nick had joined Embarcadero as the Director of Product Management, and will be overseeing Delphi as well as other Embarcadero products.

But even with that great responsibility, Nick is committed to completing this autumn's Delphi Developer Days tour. And what a special gift for our attendees. Not only are they going to hear one of the really gifted Delphi presenters, but they will be interacting with one of the people Embarcadero has entrusted with shepherding Delphi, and other products, into the future.

There are still some seats available for our Chicago and Baltimore events, and Frankfurt is almost full (Copenhagen has been sold out for over a month now). So, if you want to be a part of one of the coolest Delphi events this year, you have got to act soon. Oh, yeah, and you get your own copy of this year's Delphi Developer Days 2016 book. (Sorry, this book is available only to Delphi Developer Days attendees.)

Tuesday, October 11, 2016

When Migrating to FireDAC, You Must Understand UpdateMode

Let's start with a little history lesson. When Delphi first shipped it had one data access framework, the Borland Database Engine (BDE). While the BDE was a breakthrough product in its early years, providing a fast, independent, and easy-to-use data access layer, it was cumbersome to install, used a lot of network bandwidth, and had limited support for remote database servers. Over time, it became increasingly obsolete.

The need for a new data access mechanism for Delphi became even more apparent during the development of Kylix, a Delphi-based compiler and IDE (integrated development environment) for Linux. Porting the BDE to Linux was ruled out, and dbExpress was born. The dbExpress data access framework is high-speed and client/server friendly, largely based on pass-through SQL (structured query language).

The dbExpress framework has one major drawback, however. In most cases converting a BDE project to dbExpress required a major refactoring of the data access logic, and dbExpress did not support the old-style file server databases, such as Paradox, dBase, or MS Access until Delphi XE2. As a result, for most many developers dbExpress was a poor option.

FireDAC changes that. Conversion from the BDE to FireDAC is pretty smooth, and Delphi even ships with a tool, named reFind, that helps with much of the conversion process. It is for this reason that I use FireDAC in all of my new projects (and all of the database projects included in my source code for Delphi Developer Days). In addition, I think that a good argument can be made for migrating legacy applications to use FireDAC when a major revision is scheduled. Yes, it is that good.

One Big Difference: UpdateOptions.UpdateMode

One reason why migration to FireDAC from the BDE is so easy is that FireDAC provides a solid implementation of the TDataSet Interface, and all of the basic operations available in the BDE can be found in FireDAC. Better still, FireDAC implements many of the higher-end features previously only found in ClientDataSets. As a result, if you know the BDE and/or ClientDataSets, using FireDAC is a no brainer.

There is one very significant difference between how FireDAC and the BDE/ClientDataSets work, and this difference is very easy to miss, in part because it is related to the default value of a single property. And because the effects of this property have such a profound impact on how your database applications work, it is important that you know about this difference when you decide to start using FireDAC. The property is UpdateMode.

UpdateMode is a property found in the UpdateOptions property of FireDAC TDataSets. It is also a property of BDE TDataSets as well as the TDataSetProvider when used to apply updates to a caching ClientDataSet. In all of these mentioned classes the UpdateMode property performs the same task, it influences how the corresponding component generates the SQL used to write changes to the underlying database.

The UpdateMode property is of the type TUpdateMode. The following is the declaration of the TUpdateMode type:

TUpdateMode = (upWhereAll, upWhereChanged, upWhereKeyOnly);

Here is how it works. When UpdateMode is set to upWhereAll, all non-BLOB fields are included in the WHERE clause of UPDATE and DELETE queries. This results in update failures if any of the non-BLOB fields of the underlying record were modified since the time that the table was opened, the query or stored procedure was executed, or the FDMemTable was loaded. This approach is known as optimistic locking, and when two or more users are trying to apply changes at about the same time to the same record, only the first to apply changes will succeed. All others will fail.

When UpdateMode is set to upWhereChanged, only the primary field keys and the fields that have been modified are included in the WHERE clause of UPDATE queries. (Again, INSERTs are not affected. DELETE queries continue to use an exact match criteria since there are no changed fields in a deleted record.) As long as none of the primary key fields of an updated record are affected, and all non-primary key fields that have been modified have also not been updated in the underlying table since the time the data was loaded into the DataSet, these queries should succeed.

Using upWhereChanged permits two or more users to apply their changes to the underlying database so long as none of them have made changes to common fields. For example, if one user changed a field called Address, and another changed a field called PhoneNumber, and neither of these fields are part of the primary key, both users will successfully apply their changes. This type of update permits merges.

The final UpdateMode value is upWhereKeyOnly. With UpdateMode set to upWhereKeyOnly, the WHERE clause of UPDATE queries only includes the values of the primary key fields. (INSERT and DELETE queries continue to act as they do with upWhereChanged.) Using this mode, so long as the key fields of the underlying record have not been changed, the updates are applied, replacing any updates that other users may have applied.

Assuming that key fields are not touched (this is a pretty safe assumption in most database architectures), the use of upWhereKeyOnly permits everyone to succeed in posting their changes. As a result, the last user to post is the user whose data appears in the underlying database.

The Difference and Why It Is Important

The default value of FireDAC's UpdateOptions.UpdateMode is upWhereKeyOnly, and this is a really big deal. It means that if you use FireDAC datasets without changing this default value, there is a good chance that some users may report that their changes have disappeared. Or, even worse, never know that their edits have been overwritten.

Here is how this can happen. If two or more users read the same record (by way of a query, stored procedure call, or by opening an FDTable), and two or more post a change to that record, the last user to post their record will replace those changes posted before them. What's problematic about this is that the users who posted before the last user will have no idea that their changes have been overwritten.

By comparison, most developers prefer to use either pessimistic locking (the first user to start editing the record prevents any other user from editing the record until changes have been posted), or optimistic locking (once the first user posts a change to a record, subsequent attempts to post to that same record will fail, since the original record no longer can be found, based on the WHERE clause predicates). In these scenarios, the first user to post wins, and other users must first re-read the record, after which they can decide whether or not to update the newly posted contents.

FireDAC defaults to an UpdateMode of upWhereKeyOnly, since the queries required to update the database tend to execute faster. It is up to you, however, to decide whether or not the performance improvement is more important that the possible loss of data.

The DataSetProvider class, the class which ClientDataSets use to resolve changes back to the underlying database, and BDE DataSets (TTable, TQuery, and TStoredProc) also have an UpdateMode property. For these objects, the default value of UpdateMode is upWhereAll, the conservative setting that prevents a user from overwriting another user's edits.

So, the bottom line is this. You need to understand how FireDAC's UpdateOptions.UpdateMode affects how records are updated in the underlying database, and set this property to the value that meets the needs of your application.

An Easy Solution, If You Want to Change UpdateMode

Fortunately, another feature of FireDAC makes it easy to change the default value of UpdateOptions.UpdateMode property. The UpdateOptions property, like a number of other properties in FireDAC, is found in a number of classes in the FireDAC framework, including FDManager, FDConnection, FDQuery, FDMemTable, and so on.

These classes are related in a hierarchical sense, in that the settings found in the UpdateOptions property of the FDManager (a singleton object) are inherited by all FDConnections configured to use the FDManager. Similarly, any FireDAC dataset, such as an FDQuery or FDMemTable, will employ the settings found in the FDConnection to which they are connected.

So, if your application is using one FDConnection, changing the UpdateOptions.UpdateMode property of that FDConnection will automatically apply that setting to any FDTable, FDQuery, FDStoredProc using that connection (so long as you have not already touched the UpdateOptions.UpdateMode property on any of these TDataSets). If you are using more than one FDConnection, add an FDManager and change the value of the UpdateOptions.UpdateMode property there, and that change will likewise cascade down to any FDConnections, and then on down to the individual TDataSets, again, so long as that property has not also been overridden in any of the individual FDConnections or TDataSets.

Note that if your FDQuery, FDStoredProc, or FDTable is already connected to an FDConnection, and that FDConnection currently uses upWhereKeyOnly, changing the FDConnection UpdateOptions.UpdateMode property alone might not change the FireDAC DataSet. You might have to disconnected, and then re-connect the DataSet to the FDConnection before the DataSet's UpdateMode property updates.

Copyright © 2016 Cary Jensen. All Right Reserved