Forum OpenACS Q&A: Transferring crucial data to a fresh install

I made something very stupid. I found a bug in Photo Album package that made it impossible to delete an album if you had renamed it before. All I got was a database error.

So I found a new version of the package at Jeff's site (http://xarg.net/), installed it and run the data model update scripts. Then, when I tried to get to the Photo Album home page, I always got an database error. I thought I could get back to an earlier version, but it wasn't that easy when you already had modified the data model.

At the end I thought I should make a clean install of OpenACS, since my other test instance seems to be a lot faster than "production" server which has a lot of unneeded crap in it.

So, to the question: The only important data that I have on the server is (I think) user data, lars-blogger data and comments (and some static pages, but moving them is not a problem). What would be the easiest way to get these data to the new instance as such, without losing anything important?

Thanks, Jeff. I checked out 4.6 from cvs. The problem is that I seem to have also the package manager a bit messed up, since install packages link results in an error (shown in the browser window. I can send the clips from logs if needed):

Request Error

Selection did not return a value, and no default was provided
    while executing
"db_string apm_higher_version_installed_p {}"
    (procedure "apm_higher_version_installed_p" line 5)
    invoked from within
"apm_higher_version_installed_p $package_key $version_name"
    ("foreach" body line 8)
    invoked from within
"foreach spec_file $all_spec_files {
    array set version [apm_read_package_info_file $spec_file]
    set version_name $version(name)
    set package_..."
    ("uplevel" body line 37)
    invoked from within
"uplevel {
    	  ad_page_contract {

    Select, dependency check, install and enable packages.

    @author Bryan Quinn (bquinn@arsdigita.com)
    @c..."
    (procedure "code::tcl::/web/suisse-dev/packages/acs-admin/www/apm/packag..." line 2)
    invoked from within
"code::tcl::$__adp_stub"
    invoked from within
"if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is up-to-date
      adp_init tcl $__adp_stub
..."
    ("uplevel" body line 3)
    invoked from within
"uplevel {

    if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is up-to-date
      adp_init t..."
    (procedure "adp_prepare" line 2)
    invoked from within
"adp_prepare "
    (procedure "template::adp_parse" line 30)
    invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
    (procedure "adp_parse_ad_conn_file" line 7)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
	$handler
      } ad_script_abort val {
	# do nothing
      }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
	rp_serve_abstract_file "$root/$path"
	set tcl_url2file([ad_conn url]) [ad_conn file]
	set tcl_url2path_info([ad_conn url]) [ad_conn path_inf..."

It can as well be, that the tricks you mentioned help to this, too. Could you share a bit details about what should I exactly do to procs and tables, and which procs.

OK, I'm done. There was some problems running the drop scripts because of some crap that had been left in the acs_object_types and acs_attributes, but step by step it eventually went okay.

Thanks for your advice, I'll drop you a line about the new version of the package.