A big, big blog

I only had a little time yesterday to follow up on this issue (the priority is low as we know that making the user a non-DBA works) but I’ll document what I have encountered.

The programmatic solution I mentioned

connection.getConfig().setFeature(DatabaseConfig.FEATURE_SKIP_ORACLE_RECYCLEBIN_TABLES);

was dependent on me using DBUnit 2.2.2. I was using DBUnit 2.2 and had to upgrade.
On upgrading to DBUnit 2.2.2, I discovered that a new dependency had been introduced on slf4j. I then discovered that the dependency was on version 1.4.3 (not version 1.5, which I had installed). Eventually, I had all of the correct libraries but, sadly, the AmbiguousTableNameException was still being thrown.

Whilst DBUnit will now ignore all tables that begin with BIN$, my user has access to all tables in the system and some of those may be repeated for different users (the one I am currently failing on is DR$CLASS).

I will leave this investigation now as I’m happy for my test user not be a DBA.

Over the past couple of months we’ve had the good fortune to welcome James Pott and Cory Prowse to Gigantiq. Both are fantastic additions and have already been busy with ideas to develop the company.
At the moment, I’m lucky enough to be on the same team as James and Cory and I’m really enjoying the experience. Their passion for software development has certainly reinvigorated me; I’ve been on a podcast mega-marathon this week in an effort to keep up with some of their technology discussions.

It’s quite amusing that the group of us at the same client are popping to the gym next door on a regular basis. It may even realise Andy’s bizarre dream of having a team of Gigantic Software Developers at Gigantiq. I’ll have to order a few more of those 5XL corporate polos.

We had a problem this week whilst using DBUnit to set up some test data. A quick google didn’t really reveal much so I’ve included a (snipped) stacktrace to help anyone who also encounters this problem:


Caused by: org.dbunit.database.AmbiguousTableNameException:
BIN$S/1W2ofvNM7gQAB/AQEkDA==$0
at org.dbunit.database.DatabaseDataSet.initialize(DatabaseDataSet.java:140)
at org.dbunit.database.DatabaseDataSet.getTableMetaData(DatabaseDataSet.java:186)
at org.dbunit.operation.AbstractOperation.getOperationMetaData(AbstractOperation.java:59)
at org.dbunit.operation.AbstractBatchOperation.execute(AbstractBatchOperation.java:130)
at ...


Our quick fix (based on a hunch) was to ensure that the database user did not have DBA privileges. We’re using Oracle 10g XE and this privilege change was easy to make using Oracle APEX. As soon as we’d changed the user privileges, the exception went away.

Now that the weekend is here I have a little more time to investigate the cause of the problem and the (potentially) correct fix.

It looks as though this problem is caused by the Oracle’s use of a recycle bin to hold deleted objects. The objects in this recycle bin are still accessible as schema MetaData if you issue a jdbcConnection.getMetaData().getTables(..).
As DBUnit uses the schema MetaData to build up a map of tables in the schema, the duplicates in the recycle bin will result in the AmbiguousTableNameException.

Fortunately, DBUnit offers a means to ignore these recycled tables. I haven’t tried it yet (I’ll give it a go on Monday) but it looks as though you can set a property DatabaseConfig.FEATURE_SKIP_ORACLE_RECYCLEBIN_TABLES on the connection and all should be fixed.

I’ll update the post on Monday to let you know if it worked.