View Single Post
Old 11-03-2005, 10:37 AM
loquin's Avatar
loquin loquin is offline
Google Hound

Retired Moderator
* Guru *
Join Date: Nov 2001
Location: Arizona, USA
Posts: 12,400
Default File I/O - Ugh!

The need to store data in a non-volatile manner has been with us since the earliest days of computing. (In fact, LONG before the days of computing, but that's another story...) Imagine if the cavemen had had to paint new drawings on the cave wall before they could hold their ceremonies! Ugh. Where would we be today?

Windows APIs
VB6 offers many ways to retain your information from one program run to the next. The fastest method is to use the underlying Windows file I/O APIs (Application Programming Interface) While this method is the fastest, it also requires that you make informed decisions as to exactly how you will open, read, and close the data files, and is among the more complex methods to apply.

VB Native File I/O
If you don't need the API approach (and MOST applications do not) then, you can use VB's native file I/O methods. VB's native File I/O is closely layered atop the Window's APIs, and adds little overhead. Again, most applications will see little difference between the API approach, and VB native file I/O. GavinO's File I/O Tutorial is a very handy discussion of the various native file I/O methods in VB. The native file I/O methods include sequential text file I/O, random record file I/O, and binary file I/O.

FSO (File System Objects) is Microsofts latest approach to File I/O. While FSO is object oriented, and it is the only method of file I/O available in ASP, it adds quite a bit of overhead in the form of a large dependency, and it is substancially slower than VB6's native file I/O in most areas. In addition, the version of FSO available with VB6 does not support any file format except sequential text file I/O. In the past, we've had several lively discussions over the merits of fso and native file I/O - Here is a good one: FSO Versus VB File I/O...

For those who feel that an object oriented approach is to be favored over effeciency, I would recommend that they review ChiefRedBull's VB File Handling Class. It is much more effecient than FSO, and yet retains an object oriented approach. All with no external dependencies.

INI Files
Microsoft introduced the concept of Initialization (INI) files, used for operating system data retention, with the earliest versions of Windows. An INI file is simply a text file, formatted in a specific manner. Although you CAN read, parse, and write an INI file using VB native file I/O, FSO, or with BillSoo's file handling class, Microsoft has provided specific API's for reading and writing INI files effeciently. In addition, many have written wrappers for the APIs, to simplify their use.

Windows Registry
With the introduction of Windows NT and Windows 95, Microsoft introduced the concept of the Windows Registry to retain Operating System data. In addition, they allowed (and encouraged the technique) for applications to retain their data within the registry as well. As with INI's, Microsoft provided specific Windows APIs to read and write to the registry. In addition, many wrappers have been written for registry access also. Unlike any of the other data storage approaches discussed, the system registry is location independent. The user does not need to know the physical path to a data file.

VB / Registry
Writing to the registry, and to a lesser extent, writing to INIs allows a user to alter operating system parameters, as well as save/restore application data. If done incorrectly, however, it is possible for a user to make their operating system inoperable. In order to alleviate this issue, yet still allow users to store application data in the registry, Microsoft has added three VB functions (GetSetting, SaveSetting, and GetAllSettings,) which use a well defined location in the User application software section of the registry. Although less flexible (and powerful) than the API approach, these functions allow the user access to the registry without the danger of accidently rendering Windows inoperable.

Which approach you follow for data storage and retrieval is up to you. If you are storing lots of data, and data which can change frequently, it is not recommended that it be stored in the registry. Increasing the registry size makes many Windows operations slower, especially those which run at startup. And, Registry operations are among the slowest of all data storage/retrieval options to begin with. The registry is designed to store information about HOW your application will operate and appear, but NOT user data, unless the user data is small in size, or will not be needed often after the application starts up. One common use is to store form positions and sizes. In addition, registry data is not easily portable between machines. INI files are used in a similar fashion, but, they ARE portable. They may be freely copied from one machine to another. And, since they do have a well defined structure, many application vendors are moving back to INI files for their applications.

Each of the approaches discussed have their own specific set of advantages and disadvantages. It is up to you, as a programmer, to evaluate the approaches, and to make an informed decision as to the approach that you will follow with each application.
"I have my standards. They may be low, but I have them!" ~ Bette Middler
"It's a book about a Spanish guy called Manual. You should read it." ~ Dilbert
"To understand recursion, you must first understand recursion." ~ unknown

Last edited by loquin; 02-06-2006 at 01:28 PM.
Reply With Quote