[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-tracker] [bugs #6259] Upgrade from 0.9.14.007 to latest CV
From: |
Alejandro Borges (lex) |
Subject: |
[Phpgroupware-tracker] [bugs #6259] Upgrade from 0.9.14.007 to latest CVS failed |
Date: |
Fri, 23 Apr 2004 19:03:30 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6) Gecko/20040414 Epiphany/1.0.8 |
This mail is an automated notification from the bugs tracker
of the project: phpGroupWare.
/**************************************************************************/
[bugs #6259] Latest Modifications:
Changes by:
Alejandro Borges (lex) <address@hidden>
'Date:
Fri 04/23/04 at 23:03 (Mexico/General)
What | Removed | Added
---------------------------------------------------------------------------
Resolution | None | Fixed
Assigned to | alexbsa | jarg
Status | Open | Closed
/**************************************************************************/
[bugs #6259] Full Item Snapshot:
URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=6259>
Project: phpGroupWare
Submitted by: Peter Bodnar
On: Thu 10/30/03 at 23:48
Category: API - Setup
Item Group: 0.9.16RC1
Severity: 5 - Average
Priority: 5 - Normal
Resolution: Fixed
Assigned to: jarg
Status: Closed
Component Version: CVS
Platform Version: GNU/Linux - Debian
Reproducibility: Every Time
Summary: Upgrade from 0.9.14.007 to latest CVS failed
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.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Fri 04/23/04 at 10:36 By: mexico
sorry for long time response, i was out of country
this problem is solved in production release, you can close this bug
-------------------------------------------------------
Date: Wed 12/03/03 at 16:35 By: jarg
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.
-------------------------------------------------------
Date: Fri 10/31/03 at 22:27 By: mexico
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
-------------------------------------------------------
Date: Fri 10/31/03 at 21:29 By: mexico
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
-------------------------------------------------------
Date: Fri 10/31/03 at 16:30 By: jarg
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.
-------------------------------------------------------
Date: Fri 10/31/03 at 09:03 By: mexico
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?
-------------------------------------------------------
Date: Fri 10/31/03 at 04:59 By: skwashd
pass the buck!
-------------------------------------------------------
Date: Fri 10/31/03 at 02:30 By: cw
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.
For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=6259>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Phpgroupware-tracker] [bugs #6259] Upgrade from 0.9.14.007 to latest CVS failed,
Alejandro Borges (lex) <=