You are here: Basics Operations & Concepts > Activation > Transparent Activation > Transparent Activation Pitfalls

Transparent Activation Pitfalls

Transparent Activation is a powerful feature that can make development much faster, easier and error-proof. But as any power it can lead to trouble if used in a wrong way. The aim of this chapter is to point you out to typical pitfalls, which can lead to unexpected and undesired results.

Not Activate Call Before Field Access

Before accessing any field you need to call the activate-method. This is true for all property and also for other methods like the to string method or the hash code method. The best strategy is to call the activate-method in the property and then access the field through those even in the class itself.

Or use the enhancement-tools to avoid this issue complete.

Migrating Between Databases

Problem

Transparent Activation is implemented through Activatable/IActivatable interface, which binds an object to the current object container. In a case when an object is stored to more than one object container, this logic won't work, as only one binding (activator) is allowed per object.

Solution

To allow correct behavior of the object between databases, the object should be unbinded before being stored to the next database. This can be done with the following code:

.NET:

myObject.Bind(null);

For more information see an example.

Debugging Instrumented Classes

Debugging instrumented classes may not work 100% correct. Make sure you use the debug-flag for the db4otool

You should be able to debug normally anywhere around instrumented bytecode. If you still think that the problem occurs in the instrumented area, please submit a bug report to db4o Jira.