Error when copying (recycling) datareaders

Paul Wyatt

The problem:
A datareader is copied and amended to do something else, in my case it was with COUNT cubes. A table used in the donor datareader is deleted, the datareader configured and saved. On running the new datareader, the time taken to complete is particularly long and on opening to investigate, it is found that the table which was deleted has re-appeared and is not joined to anything. Furthermore, attempts to delete the offending table continually fail and the analyst must delete and build the table from scratch.

 

The cause:
In my case, a COUNT datareader must have a table entry in the cube field before a '1' can be used to overwrite the table reference. If the donar table reference is from the table that was deleted, the table retains a presence but unjoined and so will cause a long delay in running the datareader, possible resulting in an error. It should be noted that if you try to create this error, BOARD will catch the error and present the message informing you that 'You cannot have more than one table without a join'.

 

The solution:
Look at the SQL script which the datareader will run. The deleted table will be clearly seen as present. Delete the manual entry by selecting a field reference of a table required for the datareader to function. then, replace this reference with the figure '1', if you're creating a COUNT cube, and save the datareader, confirming that the offending table in no longer seen in the SQL script.

 

History

I appreciate that this issue may only occur with lazy DEVs who copy datareaders and don't check the SQL before saving, running and incorporating into the daily load...like me. But, it is another legitimate error where an object has been removed but the BOARD structure has failed to fully clear it from the data processes. As such, I submit this as a torchlight shining into the mirky corners of BOARD and flushing out those fiendish little gremlins which cost us hours in investigating issues either self inflicted or inherited.

 

Personal Expectation:

If I only save one poor witless DEV from spending his Saturday chasing such gremlins, I will have the satisfaction of knowing that I have succeeded in my mission of exposing my stupid mistakes so that another doesn't have to make them. We 'Boarders' are ...fragile creatures.  We need looking after in order to survive and grow.

Previous Member

Thank you Paul for sharing with us your experience.

We will consider this when designing the HTML editor of the datareader, if we can do something to avoid it we certainly will do it.

Not 100% sure that it can be avoided because it's very difficult to prevent,

 

thanks!

 

Antonio