CMemMapFile v1.55

Just to let everyone know that v1.55 of CMemMapFile has been released. Updates for this version include:

• Updated class to be completely MFC independent. You can now use CMemMapFile in an ATL only project. Thanks to HaeRim Lee for prompting this update.

CMemMapFile v1.54

Just to let everyone know that v1.54 of CMemMapFile has been released. Updates for this version include:

• Updated copyright details
• Updated code to clean compile on VC 2010
• Replaced ASSERT calls with ATLASSERT
• Updated MapMemory and MapFile methods to include a new BOOL bNoCache parameter. Thanks to HaeRim Lee for providing this nice update
• Removed m_bOpen member variable and all code which uses it. This can avoid thread safety issues when a class instance of CMemMapFile is shared across threads. Thanks to HaeRim Lee for providing this nice update
• Reworked the code in CMemMapFile::UnMap to call ReleaseMutex directly instead of calling Close. This method now shares the same consistent ordering of object creation / destruction as the main Map… methods. This also fixes an issue where the mutex previously got released twice. Thanks to HaeRim Lee for providing this nice update
• The whole class is now implemented in Memmap.h and the Memmap.cpp module is now defunct and redundant. You now just need to #include the Memmap.h in client code to use the class.

Advertisement

ODBCWrappers v1.02

Just to let everyone know that v1.02 of ODBCWrappers has been released. Updates for this version include:

• Removed final occurrence of std::auto_ptr usage in CStatement::GetCursorName.

ODBCWrappers v1.01

Just to let everyone know that v1.01 of ODBCWrappers has been released. Updates for this version include:

• Updated code to use std::vector instead of std::auto_ptr for allocating SQLTCHAR temp heap arrays. Thanks to Andrey Karpov for reporting this issue.
• BrowseConnect method which returns a string& parameter now uses a TCHAR* parameter instead of a SQLTCHAR* parameter for the first parameter

ODBCWrappers v1.0

Just to let everyone know that v1.0 of ODBCWrappers has been released. This is a set of C++ classes to encapsulate ODBC on Windows.

The classes provided are: CODBC::CHandle, CODBC::CEnvironment, CODBC::CConnection, CODBC::CStatement & CODBC::CDescriptor.

CHandle provides a class based encapsulation of a SQLHANDLE handle and the various ODBC v3 APIs which work on any SQLHANDLE type handle.

CEnvironment derives from CHandle and provides encapsulation of a ODBC environment handle. This class allows configuration of ODBC for initial usage and creation of connections to a database

CConnection derives from CHandle and provides encapsulation of a logical connection to a database.

CStatement derives from CHandle and provides encapsulation of an ODBC "statement" which allows execution of commands against a ODBC connection.

CDescriptor derives from CHandle and provides encapsulation of an ODBC "descriptor".

Finally ODBCWrappers provides a framework which provides accessor maps similar to the macros provided by the built in Visual C++ ATL OLE DB Consumer templates. These provide a simple mapping from code using OLE DB and these templates to equivalent ODBC functionality. This should provide a easy migration path if you want to move your OLE DB code to ODBC now that Microsoft have recommended that all new native mode development should use ODBC going forward instead of OLE DB at least when talking to SQL Server (http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx). Similar to the OLE DB classes, both static accessors (CODBC::CAccessor) and dynamic accessors (CODBC::CDynamicColumnAccessor) are supported. This decision by Microsoft was one of the driving reasons to implement ODBCWrappers in the first place as the only ODBC classes available in Visual C++ are MFC specific (CDatabase/CRecordSet etc) and in-line with Microsoft’s strategy it really does not make sense to restrict our usage of ODBC to MFC specific use cases going forward. The development of ODBCWrappers took a number of months of hard work researching, developing and testing and hopefully you should find them useful in your C++ database programming efforts.