I had this exact same problem which I fixed with an identical piece of code.
Huge apologies for not posting it but I'm pretty new to ojb and was working with release rather than CVS code... I've pulled the new file from cvs and can confirm that it works fine with jrun / MS SQL using Macromedia's JDBC driver. Cheers, Brendan. -----Original Message----- From: Clute, Andrew [mailto:[EMAIL PROTECTED] Sent: 12 February 2004 15:18 To: OJB Users List Subject: RE: Bug in AbstractSequenceManager found!! Armin, First off, yes, it does work. Thanks! Feel free to commit to CVS. Second, I want to apologize. I get frustrated with people at my work that don't attempt to solve their own problems, and it seems that I did the same thing to you. I was on my way out the door from work yesterday when this creeped up in my upgrade to the latest from HEAD. I was in a rush to get an email to the list before I left so you would see it first thing in the morning, and I didn't spend anytime to actually find the solution. As soon as I got home from my commute, I looked at it, and came to the same fix that you did, about 10 minutes before you sent your email out. So, once again, thanks! -Andrew -----Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 7:04 PM To: OJB Users List Subject: Re: Bug in AbstractSequenceManager found!! Hi Andrew, oops, my fault! I can't test this sequence manager implementation, because I don't use MSSQL. Seems we have to override getUniqueValue method of AbstractSM.. I attached a new version of SequenceManagerMSSQLGuidImpl - hope it will pass the apache server ;-) Can you verify this class? regards, Armin Clute, Andrew wrote: > I recently updated to HEAD of CVS, and it exposed an issue I have > within the AbstractSequenceManager. > > I was the original author of the SequenceManagerMSSQLGuidImpl sequence > manager, with it's goal to be to allow the use of MSSQL's unique > identifier as their primary key. When the SequenceManagerMSSQLGuidImpl > was written, the code inside of AbstractSequenceManager (v 1.10) would > do a check of the JDBC type of the primary key field, and the call the > apporpriate getUniqueX field. > > Because the MSSQL unique identifiers come back best as VARCHAR's (they > look like this '3C6D40F6-F961-49F2-B7F4-BAAA48B8F1F3'), I had them > defiend as varchar's in the repository, and AbstractSequenceManager > would see that and call the getUniqueString() method on the sequence > manager, and all would be fine. Worked like a charm. > > However, the code in AbstractSequenceManager (as of v1.11) now no > longer does that type check, and just assumes that getUniqueLong() > will work and blindly calls that! Opps! That won't work for the > SequenceManagerMSSQLGuidImpl because there is no way to return a long > representation of the GUID string that is returned from MSSQL. > > So, that makes SequenceManagerMSSQLGuidImpl broken, as it has no way > to return a valid PrimaryKey. > > Is this something we should fix, or am I out of luck now with my > SequenceManagerMSSQLGuidImpl? > > Thanks > -Andrew > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
