Make CPLODBCSession and CPLODBCStatement member variables protected, not private
Expected behavior and actual behavior.
CPLODBCSession and CPLODBCStatement member variables are private, so it's not possible to derive from them if one wants to add some features & helper methods.
Would it be possible to make them protected?
Operating system
Windows 10, Visual Studio 2019
GDAL version and provenance
GDAL 3.5.1-2 from OSGeo4W
if one wants to add some features & helper methods.
what would you want to do exactly ? Those classes are mostly intended for GDAL driver usage, not that much for external usage
We have several applications using FDO and OLE DB, running on Windows. We want to migrate to GDAL for portability and we'd like to use the GDAL support classes for database access, rather than roll our own. But we need some ODBC functionality that the CPL classes don't provide currently. As a matter of example:
SQLBindParameter()support;- static cursors (i.e. not the default "forward only" cursor);
- connection & statement timeout.
Some of this can be done with helper functions, but deriving from the mentioned classes and adding some methods seems the easiest and cleanest way forward. But we can't do that cleanly if the member variables are private. Making them protected seems straightforward and I don't see any undesirable side effects.
We'll be happy to submit our additions for integration into the CPL classes, if deemed interesting, but we can't stall development until we wait for a new GDAL release with the functionality we need. And we'd rather avoid rebuilding GDAL, we prefer to use prebuilt binaries.
ok, you may submit a PR adding the protected keyword you may also have a look at https://github.com/nanodbc/nanodbc that might already have what you want.