Am 24.10.2007 um 23:57 schrieb Brian Helstien: > I'm currently running Dspace 1.3.2/Oracle/Solaris 9/ > on my production server. > > I want to conduct an upgrade to 1.4.2. > I successfully upgraded my test server to 1.4.2. ... > I dropped entirely my Oracle database on my test server, > exported the production db into test, and then tarred > and moved /dspace_source and /dspace directories onto test. > I've edited my dspace.cfg to point to the test Oracle db > and the test server, updated my wars and started Tomcat ... > I have changed both the dspace.cfg handle number and the > handle config.dct files to represent my test server handle. > How do I change the just the handle prefix number associated > with the entries. I've seen the entry regarding migrating > data from test to production entry on the wiki and isn't > what I need. How do I change the just the handle prefix > number associated with the entries. ... > Do I just need to modify all the prefix numbers in the > Oracle db or is this handle value stored elsewhere?
As far as I know, the handle prefix is in the files you told and the only place for handles is in one table in the db. There is a script that comes with DSpace to do what you want to do. I think that this is what you think is not the right thing for you, but I suggest that you take a second look. I think this script does not touch the second half of your handles (behind the slash) but changes only the prefix in all database entries. Besides, I dont understand exactly why your handles would have changed unless you created new items during testing. Depending on what you did exactly when exporting your production db to test (e.g. dump production and run the dump on the test machine, then running the sql upgrade script), the database should still contain all valid handles unaltered. The settings in dspace.cfg apply to new items only and the config.dct change made sure that your test server did not answer external resolution requests, thats all. If you are not sure, I would block the production system for write access and do the same steps you did for testing once more, with a snapshot of the latest production data- base, then switch to the new machine. I would move only the /dspace dir containing the assetstore, but not /dspace_source. You have your 1.4.2 sources already there. If you have to merge local changes, then you have to do that in advance and this will be the largest task of your migration. I would use a local cvs or svn repository to simplify that step ( I actually did it that way already). I would use the new config files as a template and merge with the values of the old configs. For the handle server, I would do the same, as there was a fix in the configuration script for 1.4 that did not make it backwards to 1.3.2. I guess that you did not notice this since you did not try with your proper handle prefix. If you run into this, then you will notice it because your handle server just wont start. You can increment the version which is not the software version of the handle server but the version of your local service. You can and *should* copy the key files unaltered. as of my understanding. Thats it. Bye, Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
