Using LLBLGen 4.2, adapter.

I have an issue in dealing with fetching/setting a null value from an Oracle VARCHAR2 field in Oracle.

If I set the entity field value to "", then the database is setting this as a null. So when I refetch, it's coming in as null. On the next save, when I set it to "", then llblgen is seeing this as a change and doing an UPDATE.

I'd like to avoid these unneeded UPDATES for performance reasons.

Per: https://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=11625&HighLight=1

I believe the suggestion in the forums was to override: PreProcessValueToSet in the base object, so a "" is set to null...thus avoiding the UPDATE.

This seems like good behavior for Oracle, but our app shares the same entities for operating the app either in SQL Server -or- Oracle.

In the PreProcessValueToSet method, how can I detect the database type used, so I only do this behavior for Oracle?

For supporting different behavior for both Oracle and SQLServer (SQL Server, just using the default behavior), is PreProcessValueToSet the best place to do this?

Thanks!

In PreProcessValueToSet you are inside a adapter Entity object, so you don't have persistence information at that point. What happen if you leave that code for SQLServer as well?

The issue with leaving the code for SQL Server is that (for existing entities in the database), the fields in the database that have an empty-string (when the entity is fetched) will pull it in as an empty string, then this new code will set them to null. This will trigger an update of all those records, when nothing has actually changed. It will also leave a mixed state of empty-string -vs- null for all the string fields in the database (those more recently updated having null, and the older updated ones having empty string).

I suppose neither of these is an absolute show stopper, but it adds more states to the process and a little more complication (forever on this)...and less complication is always much better when trying to diagnose issues in the future.

IMHO, you should leave the code that way and spec that at the end you will have null values both in Oracle and SQLServer. For the problem you mention you could simply do a massive update on that field on your DB.

You also could work with default values on your DB side.

Hi Daelmo,

Thanks for the thought...good Ideas! That's a good idea that we can add a bulk update to our database script...to make things consistent for the future.