ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Storing the MSGID to a oracle table ...

Post new topic  Reply to topic
 Storing the MSGID to a oracle table ... « View previous topic :: View next topic » 
Author Message
schroederms
PostPosted: Thu May 26, 2005 11:30 am    Post subject: Storing the MSGID to a oracle table ... Reply with quote

Disciple

Joined: 21 Jul 2003
Posts: 169
Location: IA

We have a MESSAGE_DETAIL table here that I'm wanting to update after the message is on it's way back to the client in our EAI applications. I've been able to store the MSGID to a varchar2 oracle table, however the data gets converted to a ASCII string. Then when I want to take the InputRoot.MQMD.CorrelID and read the table, the data is in a HEX representation, and the data is not able to be read.

Has anyone ever tried to do this in an Oracle database, and if so what does your ESQL look like for the insert and select.

My select I've tries many variations of a Passthru. The last worthless attempt looks like this:
PASSTHRU('SELECT APPID
FROM EAI_MSGSRV.MESSAGE_DETAIL
WHERE CORRELID) = ?',Cast(InputRoot.MQMD.CorrelId as CHARACTER));
Back to top
View user's profile Send private message
ydsk
PostPosted: Thu May 26, 2005 2:23 pm    Post subject: Reply with quote

Chevalier

Joined: 23 May 2005
Posts: 410

Correlid is a BLOB type. So, make sure you do the CAST each time you convert it to a CHAR and vice-versa.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Thu May 26, 2005 2:42 pm    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

I always used to store the hex representation, then it would match when I compared the hex representation later.

If you insert bytes, and try to compare against hex characters... it's not going to match.

But msgId and CorreID are both 24 bytes, which is 48 hex chars. so make sure you size your column to fit.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
schroederms
PostPosted: Fri May 27, 2005 4:40 am    Post subject: Reply with quote

Disciple

Joined: 21 Jul 2003
Posts: 169
Location: IA

jefflowrey,

That's the stumper. How do you store the values at it's hex reporesentation. I worked with our DBA's, and they too are scratching there heads.

Thanks,
Mike
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Fri May 27, 2005 4:42 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

schroederms wrote:
That's the stumper. How do you store the values at it's hex reporesentation. I worked with our DBA's, and they too are scratching there heads.


CHAR( 48 )

Cast it as character, strip off the X and the ' and the other ', and go.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
schroederms
PostPosted: Fri May 27, 2005 10:19 am    Post subject: Reply with quote

Disciple

Joined: 21 Jul 2003
Posts: 169
Location: IA

Thanks, worked great.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Storing the MSGID to a oracle table ...
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.