jdbc calling procedures and DBTransaction isDirty()

Did you know that even if you create a callableStatement from the DBTransaction in your ADF/BC layer and call a database stored procedure, function, package, etc...that; and if that stored program unit that you called does DML and dirty's the transaction, the DBTransaction's isDirty() method will not go to true (unless it was true before the call)?

I did not; but now I do. And now: so do you, dear reader.

default database values

If you get an error that indicates that ADF/BC (the version out of JDev 10g) has compared the value it originally retrieved from the database to the value now in the database, and finds that they have changed; please, bear in mind that a database default value will do this on new records also!

So for example: you are now editing a record that you just created, suddenly you get this jbo error on a postback. The ADF Developer's Guide... says that in the case of columns altered by triggers associated with an insert, that you will need to check the "update after insert" checkbox in the entity for that attribute. The documentation does not specifically mention database table column default values, but these will have the same effect.

Once you realize this is what is happening you need only check these checkboxes to fix this.

adding 1 or more blank rows to your af:table for data entry

Boy am I embarressed. I read the whole 1160 ADF 10g developers guide for 4GL developers from Oracle, have professional experience with building ADF, and claim to be becoming an expert in all this stuff.

But I had failed in getting this simple thing done before successfully: have more than one rows availble in an af:table to allow data entry. I kept running into trouble with validation on the second row. I knew how to do what I wanted in Oracle*forms, just not ADF/BC/ADF Faces!

To my credit though I am sure I must have inquired of the JDev Forum at least once before on this subject. Literally I had come up with an "alternative" solution on a prior contract, but it was WRONG!

The correct solution is very simple: like it says in the manual: whenever you do a VO.create(); follow that by taking the resulting row and saying resultingRow.setNewRowState(Row.STATUS_INITIALIZED);

Then you can VO.insertRow(resultingRow), or do whatever you want.

The odd part of this is, I guess, if you have overridden your initDefaults in the VO's entity, using the entity's setters may changed the status of this VO row from STATUS_INITIALIZED to STATUS_NEW. I kinda figured that if you have setter method calls (e.g., this.set...(blah))in that method that you would not "dirty" your row or entity. I guess that is not right.

At any rate: that's how it is supposed to be done.

So embarressed.

view links internal to sql statement

There is an esoteric aspect of links that I had not really experimented with until yesterday.

First know that it is possible to write a query/view object, that contains a bind variable in the query which is not defined in the list of bind variables in the view object itself.

Why would you want to do this?

What if you wanted (for speed reasons) to put a bind variable referencing a parent query column in a subquery of a query in the child view object?

Well, if you create a view link between the parent and child queries, ADF will automatically create a bind variable on behalf of the view-link with the name "Bind_. So if the parent was DeptView, and the child EmpView, and their connecting view link was DeptView.DeptNo = EmpView.DeptNo, then at run time this view link would create :Bind_DeptNo referenceable in the child query. So you could put this in a sub-query.

At the moment this still leaves the sometimes problem that you may have to have a connecting DeptNo in the child query select clause, but that is only a problem in some cases. This bit of flexibility can be good enough in many cases.

Also this may be a case where the problem is that I am not sure just how much more flexibility ADF/BC will allow. It is quite possible that you could connect these two queries based on bogus columns like select 1 bogus_columnn, ... from ... in both the parent and child, and then change the where clause in the view link to join on :Bind_DeptNo. Maybe it is even more flexible than that; I just am not sure at this time.