FirebirdDatabaselayer 1.8 problems

Talk here about issues with one of the components hosted at wxCode, or suggest features for it.
bone
Experienced Solver
Experienced Solver
Posts: 74
Joined: Fri Nov 30, 2007 10:11 am
Location: Oz

FirebirdDatabaselayer 1.8 problems

Postby bone » Sun Jul 18, 2010 1:13 pm

In FirebirdDatabaselayer 1.8 there are some conversions to and from void pointers in the code that are not cast at all. Surprisingly it works in 32bit but 64bit is not compilable.

void* m_pDatabase = isc_db_handle var
isc_db_handle var = void* m_pDatabase
void* m_pTransaction = isc_tr_handle var
isc_tr_handle var = void* m_pTransaction

For some reason these and ISC_STATUS_ARRAY m_pStatus have been changed to void pointers.

Also wxDELETE (ie delete) is used with an array instead of delete[] or wxDELETEA

Another is DatabaseLayer.cpp 158,242,326,410,494,578,662,732,785,838,892
if (field->IsType(_("string")))
comparing a string flagged for translation with a wxVariant constant string.

There are a few other perhaps inappropriate instances of _() in the code.

I guess this is not a bug forum but it might save a few people some time. I like Databaselayer's functionality and it would be a real competitor for IBPP if services like backup, restore and sweep were present.
Cheers, John
Last edited by bone on Tue Jul 20, 2010 1:44 pm, edited 5 times in total.

bone
Experienced Solver
Experienced Solver
Posts: 74
Joined: Fri Nov 30, 2007 10:11 am
Location: Oz

Postby bone » Tue Jul 20, 2010 1:22 am

Also when an application exits in debug build there are many of these messages:
"ResultSet NOT closed and cleaned up by the DatabaseLayer dtor"
VC++8 MSW Vista 32 & 64
I haven't had time to look at why but something has changed since the last version.

bone
Experienced Solver
Experienced Solver
Posts: 74
Joined: Fri Nov 30, 2007 10:11 am
Location: Oz

Postby bone » Tue Jul 20, 2010 1:44 pm

Ah, I see the log message in DatabaseLayer::CloseResultSets(). It is misleading because it is actually cleaning up. However, it shouldn't be cleaning up if project code is right.

Because FirebirdResultSet::Close() is public it can be called from project code either directly or through delete FirebirdResultSet.

This will close the result set but does not remove it from the DatabaseLayer hashmap of resultsets. So if FirebirdResultSet::Close() has been used then the item is still in the DatabaseLayer result set hashmap and will be deleted in the DatabaseLayer destructor hence the log message.

If delete FirebirdResultSet has been used then DatabaseLayer::CloseResultSets() will crash trying to close a result set that has already been closed and deleted.

So DatabaseLayer::CloseResultSet(FirebirdResultSet*) should be used when finished with the FirebirdResultSet. This will remove it from DatabaseLayer's map of resultsets.

I suppose FirebirdResultSet::Close() might be useful where reusing the FirebirdResultSet variable but it might be better if private. Stopping use of delete FirebirdResultSet would be a little more difficult.


Return to “wxCode”

Who is online

Users browsing this forum: No registered users and 3 guests