This function writes a set of properties to a single database record on a remote Windows Embedded CE–based device.
CEOID CeWriteRecordProps( HANDLE hDbase, CEOID oidRecord, WORD cPropID, CEPROPVAL* rgPropVal );
[in] Handle to an open database. The database must have been opened by a previous call to the CeOpenDatabase function.
[in] Object identifier of the record to which the specified properties are to be written. If this parameter is zero, a new record is created and filled in with the specified properties.
[in] Number of properties in the array specified by the rgPropVal parameter. The cPropID parameter must not be zero.
[in] Pointer to an array of CEPROPVAL structures that specify the property values to be written to the specified record.
The object identifier of the record to which the properties were written indicates success. Zero indicates failure. To get extended error information, call CeGetLastError and CeRapiGetError. CeGetLastError may return one of the following values.
There was not enough space in the object store to write the properties.
A parameter was invalid.
The CeWriteRecordProps method does not move the seek pointer.
To delete a property, set the CEDB_PROPDELETE flag in the appropriate property value. This allows multiple deletes and changes in a single call, which is much more efficient than multiple calls.
No memory is freed by the callee. Pointers in the CEPROPVAL structures can be anywhere in the caller's address space — they can be marshalled in like the array returned by CeReadRecordProps, or they can be independently allocated.
For Windows Embedded CE versions 2.10 and later, on a mounted database volume, all write operations are cached. The database subsystem periodically requests a cache flush after a series of operations. If memory is low, the cache is flushed to permanent storage. Unlike a file system that can choose to flush only part of the cache, on a database, all blocks are flushed.
|Earlier versions of Windows Embedded CE assigned object identifiers to objects in other file systems, such as the file allocation table (FAT) file system. These object identifiers were guaranteed to be unique within a volume, but not across multiple volumes. Effective with version 3.0, only objects in the object store have valid, unique object identifiers and the object store is the only volume that can return an object identifier.|