Connecting 32bit client to 64bit database

[Norman Biggar]

We are experiencing a problem whereby, having upgraded our system to 10.1B on a 64 bit machine, a customer operating 10.0B on a 32 bit machine is unable to communicate through the appserver.

The message received is
** Disconnected by the server, code 44. (706)

Can anyone provide a mechanism to allow communication to proceed?

Thanks

 

[TomBascom]

You can use app servers to connect old clients to newer servers. But the server must not use any features that the client doesn't know about in a way that would require the client to become aware of them.

It is probably not a 32 bit client vs 64 bit server issue but rather a result of a 10.1B feature (such as a 64 bit rowid, a 64 bit sequence or a bigint) being used on the server which the 10.0B client doesn't know how to react to.

Probably the easiest one to accidentally trip over would be the 64 bit rowid. You would just need to have a storage area that exceeds 2 billion records (or record fragments). That is easy to have happen. Especially if you haven't really done much with storage areas. The good news is that it is probably fixable -- you just need to reorganize your storage areas so that none have more than 2B records. The bad news is that that will probably take a while. The really bad news would be if there is a single table that has that many rows -- in that case you are stuck with needing to upgrade the clients (ditto for sequences and bigints).

 

[Norman Biggar]

Thanks for the quick reply, Tom.

The customer is already connecting through an appserver to access the data through their own procedure library.

Our data is fairly well spread over storage areas and a quick examination on the most recent dbanalys report suggests we aren't anywhere near the 2 billion records on any one area.

I have noticed that it is possible to access our 10.1B database from a 10.0B session using -N -H -S. Does this mean that the client could connect to our 10.1B database using a 10.0B appserver and might this help our problem?

 

[TomBascom]

I'm having trouble following your configuration Both existing and possible.

But anyway, yes, all of that should be possible. None the less if a 10.0B client "touches" a feature that wasn't introduced until 10.1B it is going to barf. Since you're fairly sure that it isn't a row > 2B that leaves sequences and bigints as two good possibilities. I would check all sequence current values and I'd scan the meta schema for bigints before I started trying different connection strategies. It's easier to cure a problem when you know what the actual cause is.

You might also try pasting your error message into the kbase lookup. It brings up a bunch of possible hits.

 

[Norman Biggar]

Hi Tom,
It would appear that our dbanalys report was somewhat misleading. We have moved the tables accessed by our customer to a different area and this seems to have "fixed" the problem.

I suspect our next step will be to create two or three bespoke areas for these tables alone and start moving the tables around some more.

Thanks for your help,
Norman