bugphpGroupWare - Bugs: bug #6259, Upgrade from 0.9.14.007 to latest...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #6259: Upgrade from 0.9.14.007 to latest CVS failed

Submitter:  Peter Bodnar <mexico>
Submitted:  Thu 30 Oct 2003 11:48:35 PM UTC
   
 
Category:  API - Setup Item Group:  0.9.16RC1
Severity:  3 - Normal Priority:  5 - Normal
Status:  Fixed Privacy:  Public
Assigned to:  jarg Open/Closed:  Closed
Component Version:  SVN Operating System:  GNU/Linux - Debian
Reproducibility:  Every Time Planned Release:  None
Fixed Release: 

Jump to the original submission

Fri 23 Apr 2004 10:36:29 AM UTC, comment #8: 

sorry for long time response, i was out of country
this problem is solved in production release, you can close this bug

Peter Bodnar <mexico>
Wed 03 Dec 2003 04:35:55 PM UTC, comment #7: 

ok, i see the schema proc code, and i think the tables_baseline file are wrong, this file is used in upgrade for create tables when this was droped for a modification as alter_something, and in this case the table phpgw_access_log was droped but schema proc doesn't found the table definition for create this again because the table phpgw_access_log doesn't exist in the tables_baseline file.

I think this can be fixed for adding the definition for phpgw_access_log, and if you want all others tables in this file, so we have something as:

access_log => definition,
phpgw_access_log => definition

please commet.

Jonathan Rivera <jarg>
Fri 31 Oct 2003 10:27:50 PM UTC, comment #6: 

o.k., next error, which I found, was in upgrade project application - insert null data in not null column  investment_nr - old table has not set NOT NULL attribute
I don't know, if it is error or not, because project apps we are not using, it was installed only for testing and contains incomplete and unusable data, so I uninstall this app before upgrade.

Result:
with my apps (addressbook, calendar, infolog, email, inventory, tts, todo) upgrade contains only problem with phpgwapi, which can be solved with change name in table_baseline

thanks all for help

Peter Bodnar <mexico>
Fri 31 Oct 2003 09:29:15 PM UTC, comment #5: 

hmm...all names in tables baseline is without phpgw_
but all tables in tables_current begin with phpgw_
and all tables in database start with phpgw_ (exclude lang and languages)
so, i change name in tables_baseline, this upgrade run o.k, but there is other errors, I try sumarize all problems and post later

Peter Bodnar <mexico>
Fri 31 Oct 2003 04:30:22 PM UTC, comment #4: 

mm i see in this upgrade this function:

$test[] = '0.9.14.505';                                                                                                                                            function phpgwapi_upgrade0_9_14_505()                                                                                                                              {                                                                                                                                                                              $GLOBALS['phpgw_setup']->oProc->AlterColumn('phpgw_access_log' .........
}

but in tables_baseline the table name is only access_log if i change this by phpgw_access_log this works, now i don't know if the problem is with this table names in tables_baseline.inc.php or is an error in schema proc.

Jonathan Rivera <jarg>
Fri 31 Oct 2003 09:03:39 AM UTC, comment #3: 

ok, i found some rows with empty lo column.
I manualy delete this data, but upgrade failed with same error.
After that, I try next upgrade with empty access_log - same error.
My opinion - data is not problem, problem is in php scripts (but I don't know, where)

I'll try to debug php code in schema_proc_pgsql - any idea, whot I must watch?

Peter Bodnar <mexico>
Fri 31 Oct 2003 04:59:13 AM UTC, comment #2: 

pass the buck!

Dave Hall <skwashd>
Group administrator
Fri 31 Oct 2003 02:30:03 AM UTC, comment #1: 

Well, I was assigned i'm sure cause Dave thought this was related to the ERROR log changes I imported, but it's not.  This is a problem in the pgsql schema proc and is also much earlier than the error log code anyway :P

Since I have not a pgsql server, nor do I know pgsql quirks I ask to have this reassigned to someone that does.

To help though, since this step changes a varchar(255) to an int(4) I wonder if any data in your table in the 'lo' column was not really an int or null.  I know we have people using pgsql and I think at least one did an upgrade, so I wonder if it's odd data related.

Chris Weiss <cw>
Group administrator
Thu 30 Oct 2003 11:48:35 PM UTC, original submission:  

System info:
Linux Debian sid
Apache 1.3.28
PHP 4.3.3
PostgreSQL 7.3.4
phpgroupware 0.9.14.512 (latest CVS update)


After installing latest CVS version (0.9.14.512, which is working fine if installed on clear database), I tryied to upgrade from old version (0.9.14.007). In Setup, when selected Upgrade, upgrade halted with error message:

Database error: Invalid SQL: INSERT INTO phpgw_access_log () VALUES ()
PostgreSQL Error: 1 (ERROR: parser: parse error at or near ")" at character 31 )

when activate debug in setup/index.php,
I've got a messages, which ends with:

process->upgrade(): appname: phpgwapi
process->upgrade(): currentver: 0.9.14.505
process->upgrade(): targetver: 0.9.14.512
process->upgrade(): status: R
process->upgrade(): checking: 0.9.14.505
process->upgrade(): function: phpgwapi_upgrade0_9_14_505
process->upgrade(): running phpgwapi_upgrade0_9_14_505
DropSequenceForTable: phpgw_access_log
GetSequenceForTable: phpgw_access_log
DropSequenceForTable: phpgw_access_log
GetSequenceForTable: phpgw_access_logDatabase error: Invalid SQL: INSERT INTO phpgw_access_log () VALUES ()
PostgreSQL Error: 1 (ERROR: parser: parse error at or near ")" at character 31 )

after this, I look in database, and I found missing table phpgw_acces_log, there is only phpgw_acces_log_tmp with old structure. After trying read/debug PHP code, it's look that error is in function _CopyAlteredTable in class.schema_proc_pgsql.inc.php in phpgwapi (not create values for SQL statement).

At this time, I can't debug php code, maybe tomorow for next info.

Peter Bodnar <mexico>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 6 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-04-23 alexbsa StatusNone Fixed
    Assigned toalexbsa jarg
    Open/ClosedOpen Closed
2003-10-31 skwashd Assigned toskwashd None
2003-10-31 cw Assigned tocw None
2003-10-31 skwashd Assigned toNone None

Back to the top

Powered by Savane 3.13-3230.
Corresponding source code