Last modified: March 09, 2015
Applies to: Windows | Windows Server
The JetReadFile function retrieves the contents of a file opened with JetOpenFile.
JET_ERR JET_API JetReadFile( __in JET_HANDLE hfFile, __out void* pv, __in unsigned long cb, __out_opt unsigned long* pcbActual );
The handle of the file to be read.
Output buffer that will receive the file data.
The maximum size in bytes of the output buffer.
Receives the actual amount of file data retrieved.
This function returns the JET_ERR datatype with one of the following return codes. For more information about the possible ESE errors, see Extensible Storage Engine Errors and Error Handling Parameters.
The operation completed successfully.
The operation failed because the current external backup has been aborted by a call to JetStopService. This error will only be returned by Windows XP and later releases.
It is not possible to complete the operation because all activity on the instance associated with the session has ceased as a result of a call to JetStopService.
It is not possible to complete the operation because the instance associated with the session has encountered a fatal error that requires that access to all data be revoked to protect the integrity of that data. This error will only be returned by Windows XP and later releases.
One of the parameters provided contained an unexpected value or contained a value that did not make sense when combined with the value of another parameter. This can happen for JetReadFile when:
The operation failed because no external backup is in progress.
It is not possible to complete the operation because the instance associated with the session has not been initialized yet.
The operation failed because non-recoverable data corruption was detected while reading a database page from a database file or database patch file.
The operation failed because non-recoverable data corruption was detected while reading a transaction log file. This error will only be returned by Windows XP and later releases.
It is not possible to complete the operation because a restore operation is in progress on the instance associated with the session.
The operation failed because an attempt was made to use the engine in legacy mode (Windows 2000 compatibility mode) where only one instance is supported when in fact multiple instances already exist.
It is not possible to complete the operation because the instance associated with the session is being shut down.
On success, the next chunk of data from the file will be read into the output buffer. The actual number of bytes retrieved will also be returned. The file offset at which the next read will occur will be advanced by this amount.
On failure, the state of the output buffer is undefined. The failure will result in the cancellation of the entire backup process for the instance. On Windows XP and later releases, the backup will not be canceled if an error occurred while reading a database file. However, the backup of that database file will still be canceled and the corresponding handle will automatically be closed.
Any call to JetReadFile using a handle that has already returned all the data in the underlying file (such as a previous call returned less bytes than the size of the output buffer) will always succeed but return zero bytes of data.
A large output buffer should be used to maximize backup performance. Some experimentation may be required to find the right tradeoff between resource consumption and throughput for a given situation. The output buffer should be no smaller than 64KB in any case.
Multiple concurrent calls to JetReadFile using the same file handle are not supported. This means that it is not possible to queue several buffers for read concurrently against the same file to achieve high sequential throughput. A single large buffer should be used instead.
If the instance is configured such that database page scrubbing is enabled (see JET_paramZeroDatabaseDuringBackup in System Parameters) then deleted data will be removed from the database as a side effect of a call to JetReadFile against the database file.
It is very important to understand how backup and data corruption interact. If the database engine detects data corruption during a backup then it will either fail the backup of the affected database or of the entire instance. This is a conscious design decision intended to protect against data loss. If the database engine allowed a backup to succeed where data corruption was present then it is possible that an older, uncorrupted backup could be discarded as a result. This would be unfortunate because it would be possible to fix the data corruption on the live instance by restoring that backup and replaying all the transaction log files against that database. This zero data loss scenario presumes that circular logging is not enabled (see JET_paramCircularLog in System Parameters).
It is also important to understand that when data corruption is present streaming backup will be the most likely place that it will first be detected. This is the case because streaming backup is the only process that routinely scans every single page of the database file. It is also likely that streaming backup will be the first process to detect the early signs of hardware failure as manifested by intermittent data corruption errors. This is due to the amount of data retrieved by backup as well as the speed at which it is retrieved.
Data corruption is detected by the database engine through the use of block checksums. These checksums are set just prior to a database page write and are verified on a database page read. This scheme enables the database engine to determine that data has been corrupted at some point but it does not enable the database engine to determine the source of that corruption. Historically, the predominant cause of such corruption has been found to come from sources other than the database engine itself.
Requires Windows Vista, Windows XP, or Windows 2000 Professional.
Requires Windows Server 2008, Windows Server 2003, or Windows 2000 Server.
Declared in Esent.h.