I have an object queue which works fine with PL/SQL code on Oracle 9.2.0.5 both ways (enqueue and dequeue). Connecting to the same schema as before using Delphi 6 and DOA 4.0.6.2 and attempting a Dequeue from the Queue, I get an EVariantTypeCastError for a conversion from null to integer immediately on the dequeue statement.

The application is non-threaded, the queue ist a multi-consumer queue of type 8.1. The object type used has the following signature (quoting from the create statement):

create or replace type abholungen_qtyp as object (
id number(12),
operation char(3),
...
(some more whole number and date fields)
...
stand date,
version number(12)
);

Usually some but obviously not all of the values in a message are null. I tried replacing those with placeholder values in order to get a message totally without any null values, but that didn't have any effect. By the way, on closing the application I regularly get "TOracleObject: Invalid handle" exceptions although I close down connections explicitly. It seems to me as if the implicitly created Object that is to receive the payload doesn't get destroyed in the correct sequence on disconnects. That is just a guess however.

The strangest thing (to me) is that I first had it working for another queue, put in this one and got the errors, commented out the operations on the other queues with the errors remaining, removed the comment, and now the working queue also fails in exactly the same way. Changing the oci.dll from version 9.2.0.5 to 8.1.7.4 did not make any difference, both now fail consistently.

I am not doing anything spectacular, just a simple dequeue in the main thread with wait=1, navigation=first_message and the consumer_name set to exactly the value contained in the messages (I checked in the index IOT to make sure that was the case).

Any ideas what I may be getting wrong? Or should I perhaps upgrade my Oracle client?

I don't think the issue is related to the payload object type, but to one of the values returned to the MessageProperties. In that case we should be able to fix this.

Can you let me know what value your TOracleSession.NullValue property has?

The value for the TOracleSession.NullValue property is nvNull. I just went and changed it to nvUnAssigned in order to try out what happens then. Things started to work immediately. However, the "Invalid handle" exception on closing is still there.

By the way, I don't recall having worked with this property so far. Is there any place where it could come back and bite me on the a.. if I leave it set to nvUnAssigned?

Not meaning to be impolite, I still have a couple of questions:

- do you have any plans for a fix for the problem with dequeueing messages when having TOracleSession.NullValue set to nvNull?
- do you have any plans for a fix for the problem with "TOracleObject: Invalid handle"?

Any answers much appreciated. By the way, do you prefer such things posted here or sent per email to your support address? I thought I'd post them here since they might be of interest to other people (e.g. Fino Mornasco, who mentioned the invalid handle problem in another post). I do have a support contract, though, so I wouldn't mind either way.

Of course we'll fix this. That's why I asked the extra information. I'm not sure about the invalid handle problem yet though.

Got another problem now. To give you some more background let me say that the queues I am using are accessed through components in a data module.

What happens is that I open a connection to a remote database and start dequeueing objects waiting in a queue (if any). TOracleSession.NullValue is nvUnAssigned. Afterwards I close the connection again. No problems in the first round. If I try it a second time, I get an AV in module ora9common.dll for a read from a memory address on the first attempt to dequeue. The AV is repeatable from that point in time onwards, and both the address at which it occurs and the address it tries to read never change.

Stopping the application and restarting it delivers the same result. This was tested both from within the IDE and on a separate computer where the application was installed from scratch and no IDE is present.

Any ideas what's happening? Or what I should try to get around the phenomenon? The only thing I can think of is to go and allocate the queue objects dynamically so that they don't stick around when the session gets disconnected. That might also take care of the "invalid handle" problem. Do you that would be worth the effort?

Creating and destroying queue instances is currently the only workaround. We will fix this in the next patch release.

The workaround really does work around the problem. I have changed all my queues to dynamic allocation and deallocation, and so far I haven't encountered any problems any more. I'll have to put in another 8 queues over the next couple of days. If anything new comes up, I'll let you know. Otherwise, thanks for the help, and I'm looking forward to the next release.