It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×1,192

question asked: Apr 08 '10, 2:09 p.m.
question was seen: 8,156 times
last updated: Apr 08 '10, 2:09 p.m.

Related questions

Build Forge upgrade questions

0
Jay Curtiss (21●2●2) | asked Apr 08 '10, 2:09 p.m.
Four years ago we began a pilot of Build Forge on a Windows XP server (console + database). As often happens, pilot became Production. As usage has gone up, we have added memory and drive space. We are currently at version 7.0.2 with iFix 3 applied (7.020009 is displayed if you hover over the management console logo). The database is DB2 Universal Database Express Edition, version 8.1.17. I want to upgrade to 7.1.1.3, but I'd also like to move the database to a different machine to gain a performance boost.

I've installed DB2 9.1 (Enterprise Edition in my case) on a linux box, and I've downloaded Build Forge 7.1.1.3 from the IBM support site, but I'm left with a lot of questions on how to proceed. My situation does not correspond directly to any upgrade scenario found in the documentation. Let me lay out what I think I need to do, and sprinkle my questions into the mix. Please let me know if I'm on the right track.

1) Backup a full image of my current system
2) Upgrade the current DB2 on Windows to a level supported by BF 7.1.1.3 and verify everything still works
3) Per the install instructions: "Create the new database schema BUILD711, then create a new database user BUILD711 for the new schema. The user must have GRANT OPTION for its tables."
Question: Why do I need yet another user to keep track of? Why can't I just use the one I always use?
4) Install version 7.1.1.3 on the system where I am running version 7.0.2. I'm not migrating historical data, so I don't need the second instance on an offline system.
Question: Why do you need to use different port numbers in installing the new version when the install instructions tell you to stop the old version first?
5) Create configuration files for configuration data migration
6) Migrate configuration data
7) Troubleshoot the configuration data migration
8) Move my current database to the linux box by using the db2move command
9) Install the new DB2 client on the current machine, and get my current configuration working between the XP management console and the linux database

2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Jesus Alva (81●1●1) | answered Apr 09 '10, 11:56 a.m.
Four years ago we began a pilot of Build Forge on a Windows XP server (console + database). As often happens, pilot became Production. As usage has gone up, we have added memory and drive space. We are currently at version 7.0.2 with iFix 3 applied (7.020009 is displayed if you hover over the management console logo). The database is DB2 Universal Database Express Edition, version 8.1.17. I want to upgrade to 7.1.1.3, but I'd also like to move the database to a different machine to gain a performance boost.

I've installed DB2 9.1 (Enterprise Edition in my case) on a linux box, and I've downloaded Build Forge 7.1.1.3 from the IBM support site, but I'm left with a lot of questions on how to proceed. My situation does not correspond directly to any upgrade scenario found in the documentation. Let me lay out what I think I need to do, and sprinkle my questions into the mix. Please let me know if I'm on the right track.

1) Backup a full image of my current system
2) Upgrade the current DB2 on Windows to a level supported by BF 7.1.1.3 and verify everything still works
3) Per the install instructions: "Create the new database schema BUILD711, then create a new database user BUILD711 for the new schema. The user must have GRANT OPTION for its tables."
Question: Why do I need yet another user to keep track of? Why can't I just use the one I always use?
4) Install version 7.1.1.3 on the system where I am running version 7.0.2. I'm not migrating historical data, so I don't need the second instance on an offline system.
Question: Why do you need to use different port numbers in installing the new version when the install instructions tell you to stop the old version first?
5) Create configuration files for configuration data migration
6) Migrate configuration data
7) Troubleshoot the configuration data migration
8) Move my current database to the linux box by using the db2move command
9) Install the new DB2 client on the current machine, and get my current configuration working between the XP management console and the linux database


Hi Jay,

The reason the docs have you create a new user is that we try to keep the instructions as similar as possible across our supported databases. For the other databases we support, having a new user is essential. For DB2, creating a new user is actually not required as long as your current user has enough permissions to perform the migration operations (table create, table modify, etc).

The reason that you may want to install the new version of BF on different ports than the 7.0.x version is that if at some point you need to view the historical data that wasn't migrated, you will need to start up the old console in order to do this. If they use the same ports, this also means that you will have to shut down the new console in order to start up the old console and view the data. Just something to think about when you are choosing how to install the new version of BF. If this is not a big deal for you, then yes, you can re-use the same ports for the new and old console as you should never have both running at the same time anyway, except for special circumstances where you need to pull unmigrated data from the old console.

As for your overall upgrade process, it looks good. That should get you exactly where you need to be.
0
permanent link
Jay Curtiss (21●2●2) | answered Apr 09 '10, 3:03 p.m.
Thanks Jesus, I appreciate your time and your analysis!

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.