Nope - same trouble with DB2 9. Tried updating an Openfire 3.3.3 to 3.4.5.
I’ve spent some hours trying to make the update run. A little bit more testing before getting the release out would have been nice …
I will try the workaround mentioned above. Hope it’ll to the trick.
Let us know if it works so we can make the appropriate adjustment.
I had to make serveral adjustments to your update script to make it work. Would really have helped if you had tested the stuff in advance. You don’t have to buy DB2 for that purpose. The DB2 Community Edition is free - even for commercial use.
Please see attached db2 sql.
One special issue is the size of the vcard column in the jivevcard table. I’ve set the column to VARCHAR(30000) because VARCHAR(2000) won’t work more often than not. VARCHAR(30000) works well for me and so I’ve changed it here to. However you will need a spechial buffer pool for that purpose.
There are also some errors in the asterisks sql scripts as well (update 1 and update 2).
What do you mean by a special buffer pool?
Well - by default you will get an buffer pool named IBMDEFAULTBP with page size 4K while creating a new DB2 database. For the “new” VARCHAR(30000) column this bufferpool is not suitable, because it’s too small. You’ll have to create a new buffer pool with 32K page size. The name is of no importance.
e.g. : CREATE BUFFERPOOL MYBIGBP IMMEDIATE SIZE 1000 PAGESIZE 32 K;
As a second step you have to create a new tablespace using the buffer pool created before.
DB2 will now use the new buffer pool and table space to handle such “big columns” like the VARCHAR(30000) column mentioned above.
e.g.: CREATE REGULAR TABLESPACE MYBIGTS PAGESIZE 32 K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL MYBIGBP DROPPED TABLE RECOVERY ON;
That’s it.
Does DB2 not have the concept of a TEXT or BLOB field like other databases do? Wouldn’t it be more appropriate to use one of those and be consistent with other DBs?
Yes it does. I was thinking about that, too. A BLOB field would probably be most sensible.
I haven’t checked how you handle this stuff with the other database engines and my intention was to change the script minimal inversive if you get my meaning.
With a BLOB field there shouldn’t be any trouble with too big avatas preventing the vcard to be synchronized properly. However the java code to access such a field is supposed to be different from a normal VARCHAR. That’s the reason I haven’t tried anything like that.
However - if you tell my your code can handle that, I can give it a try.
It should be able to! We use blob in some other instances/other databases without having to modify code. Please do test that and if it works fine, let me know, and I’ll get that switched out for 3.5.0! I always did wonder why there were varchar(2000)'s in place for DB2. Quite frankly I thought it was a smarter DB than that. (in other words, smarter than not having TEXT or BLOB or something similar)
Our test was not really successfull so far. We will have to take a look at the code. I will give you feedback sometime later.