INF: Client Config. Util. Indicates Unusual DB-Library Date

• Microsoft SQL Server version 4.2x

SUMMARY

When installing SQL Server on a Windows NT 3.5 FAT disk partition, or upgrading from Windows NT version 3.1 to version 3.5 when SQL Server is already installed on a FAT disk partition, under some circumstances the DB- Library and Network Library (Net-Library) file dates indicated by the Client Configuration Utility may be either 12/31/79, or the date SQL Server was installed.

This is a side-effect of the enhanced Windows NT 3.5 FAT file system, which includes support for long filenames and multiple file date/time fields. There is no other adverse impact besides the unusual DB-Library date/time. If desired it can be corrected by re-copying the Net-Library and DB-Library files from the SQL Server distribution CD-ROM.

MORE INFORMATION

There are two sets of situations which can cause the Client Configuration Utility to display unusual DB-Library and Net-Library file dates. The first set will cause the dates to be 12/31/79, and the second set will cause the file dates to be the date SQL Server was installed.

An example of the first set would be installing SQL Server from diskette to a Windows NT 3.5 FAT partition. Another example would be upgrading the operating system from Windows NT 3.1 to version 3.5, when SQL Server is already installed on a FAT partition. This will not happen when installing from CD-ROM or during a network installation from files copied from CD-ROM to the NTFS partition of a Windows NT server.

An example of the second set would be doing a network-based installation to a Windows NT 3.5 FAT partition from a FAT partition on a Windows NT 3.1 server. More specifics are given below.

The FAT file system of Windows NT 3.5 has been enhanced to use long filenames and multiple date/time fields, generally referred to hereafter as "time fields" for simplicity. Similar to NTFS, the Windows NT 3.5 FAT file system will support three discrete time fields. These are time created, time last accessed, and time last written (or modified). By contrast the previous FAT file system which NT 3.1 shared with DOS and Windows 3.1x only supported a single time field, which was time last written. These new capabilities are achieved without altering the FAT file system structure, so that no file system conversion or upgrade process is needed. This differs from the FAT-to-NTFS upgrade process where a one-way conversion takes place.

The enhanced time field capability of the Windows 3.5 FAT file system can under some circumstances cause the SQL Server Client Configuration Utility, NTWDBVER.EXE, to display an unusual date.

The Client Configuration Utility uses the C runtime call _fstat() to obtain the file dates. Regardless of the file system used, this call returns a memory structure containing three time fields, which are st_ctime (time created), st_atime (time last accessed), and st_mtime (time last written or modified). In the case of FAT prior to Windows NT 3.5 (subsequently referred to as "old FAT"), there is only a single disk storage location for file date/time. Yet for compatibility with other file system environments such as UNIX, _fstat() returns all three fields. When called, _fstat() obtains the st_mtime field from the single disk storage location, then the st_ctime and st_atime are replicated at runtime from st_mtime. Note that with old FAT, there is no true file create time, despite the term "create time" being in common use. Rather old FAT only has "time last written, or modified".

In order to take advantage of true file creation time of NTFS, the Client Configuration Utility uses the st_ctime field returned from _fstat(). When _fstat() is executed against a file on NTFS or new FAT, st_ctime is backed by its own storage location and can store a discrete value independent from st_mtime and st_atime. When an old FAT partition is upgraded to NTFS, a conversion program rewrites the file structure. Part of this conversion program copies the old FAT time field (on disk) to the "time created" and "time last modified" disk storage fields of NTFS. Therefore if an application using _fstat() was querying the st_ctime field when under old FAT, the date returned immediately following upgrading to NTFS will be unchanged, since the FAT-to-NTFS conversion process effectively replicates on disk st_mtime to st_ctime.



By contrast, during the upgrade from Windows NT 3.1 old FAT to Windows NT 3.5 new FAT, no file system conversion takes place, only an enhanced FAT file system driver is loaded. This is actually an advantage since it enables new capabilities such as long filename support and multiple time fields, without sacrificing backward compatibility with previous operating systems using old FAT such as MS-DOS, OS/2 or prior versions of Windows NT. However since there is no file system conversion program, there is no facility for replicating the single old FAT time storage location to the new FAT time fields.

In the case of the new time fields, previously unused FAT directory entry locations are used to store these. The new fields have the initial value of 0, which _fstat() displays as 12/31/79. This is what causes the Client Configuration Utility to display these dates. There is no adverse impact from this other than the incorrect date. You can see the correct file date by using the DIR command. (Incidentally there are DIR parameters which allow inspection of all three date fields. Use DIR /s to see these.) The DB- Library and Net-Library version numbers which the Client Configuration Utility returns are correct.

The second situation in which the Client Configuration Utility may indicate a strange date/time concerns when SQL Server is installed on a Windows NT 3.5 FAT partition from old FAT source media. Examples of this would be a network-based installation from a Windows NT 3.1 server FAT partition containing the SQL Server installation files to a Windows NT 3.5 FAT partition. Installations from local or remote CD-ROM or NTFS sources are unaffected. To see this phenomenon, the SQL Server installation files must have been copied to an old FAT partition from diskette or from another old FAT partition such as that on Windows NT 3.1. If any intermediate copy is made to a partition other than old FAT (e.g. diskette to NT 3.1 NTFS to NT 3.1 FAT) then the creation date _fstat() returns will be 12/31/79, not the current date. What causes the "current date" effect is this: When a file on old FAT is copied to a new FAT partition, the destination file is created. Hence the creation time field on disk is initialized to the current date. By contrast, when copying a file from a non-old FAT partition to new FAT partition, the file already has a true creation date so this is maintained when the new file is created.

As in the case with the 12/31/79 date, if the Client Configuration Utility returns the date SQL Server was installed, this can be corrected by re- copying the DB-Library and Net-Library files from a source such as CD-ROM. There is no other side-affect to the strange date/time display, and the version number is unaffected, so re-copying the files is optional.

Additional query words: file date getfiletime fstat ntwdbver dblib

Keywords : kbprg SSrvDB_Lib SSrvWinNT
Version : 4.2
Platform : WINDOWS
Issue type :