Re: Expected Resolution Date - Tibor Gellert - com.mysql.lists.eventum-users

9 messages in com.mysql.lists.eventum-usersRe: Expected Resolution Date

From	Sent On	Attachments
Eric Carlson	05 Apr 2006 15:48
Eric Carlson	07 Apr 2006 08:25
Kraer, Joseph	10 Apr 2006 08:23
Tibor Gellert	30 May 2006 04:07
Jostein Martinsen	30 May 2006 04:16
Andrey Popovich	30 May 2006 05:05
Tibor Gellert	30 May 2006 06:43
Bryan Alsdorf	09 Jun 2006 19:48
Tibor Gellert	28 Jun 2006 10:50

Subject:	Re: Expected Resolution Date
From:	Tibor Gellert (tibo...@openet-telecom.com)
Date:	05/30/2006 06:43:35 AM
List:	com.mysql.lists.eventum-users

Yeah - its something with current locale, Smarty is sensitive to the settings on the OS/??? level.

If I modify the update_form.tpl.hmtl template at line 216, adding the following: {$smarty.now|date_format} prints " Jan 6, 114904" which is not the expected as the OS date reports May 30 2006

The 114904 figure for the year pushing up the number of elements in the combo-box big time... hence the slow response.

I am not expert of smarty so please anyone give me directions how to resolve this locale problem if something easy comes to mind!

Andrey Popovich wrote:

I have same situation. It seems that there are bug with detecting current date in update.php. I have years in "Expected resolution Date" till 147560 or something. :) That's why render of this page takes so much time (1 combo-box with year value and more that 100.000 values in it).

On Tue, 30 May 2006 13:17:03 +0200 Jostein Martinsen <jost...@redpill.se> wrote:

I might be way out but could this be a glitch in Smarty? One time I saw the same thing, and it was in a almost new install of Eventum. I was unable to reproduce the behaviour.

On Tue, 30 May 2006 12:08:08 +0100 Tibor Gellert <tibo...@openet-telecom.com> wrote:

Hi,

I am moving Eventum to a new hardware and hitting the exact same issue. Environment on old box: - Eventum 1.6.1 - SuSE 9.3 - MySQL ver 14.7 distrib 4.1.10a - Apache 2.0.53

New environment: - Eventum 1.6.1 (file system level copy) - SuSE 10 - MySQL ver 14.7 distrib 4.1.13 using readline 5.0 - Apache 2.0.54

On the old box I use mysqldump --comments --add-drop-table ... eventum_prod

ev_prod_db command to dump the data. On the new box I use

mysql ... eventum_prod <ev_prod_db to load the data.

Any luck fixing this before?

Thanks for any idea, Tibor

Kraer, Joseph wrote:

Bryan,

We've been experiencing the same issues. We discovered it in 1.7, the week before 1.7.1 was released. We waited for 1.7.1 because we thought that it was going to be corrected by then. Do you have a solution for this issue yet?

Thanks,

Joseph "Tito" Kraer Business Systems Analyst Taylor, Bean & Whitaker Mortgage Corp

-----Original Message----- From: Eric Carlson [mailto:er...@bluehammock.com] Sent: Wednesday, April 05, 2006 6:49 PM To: even...@lists.mysql.com Subject: Expected Resolution Date

Hi all, I've been receiving calls lately about the slowness of Eventum when attempting to update issues. I recently moved this database between two linux machines (Gentoo) in the previous weeks, so thought it might have been something to do with that.

As it turns out, it looks like the slowness is related to my Expected Resolution Date field. When hitting the update button, the "Year" field on Expected Resolution Date shows values from 2007 all the way up to 114,432! 2006 is not in this list.

I'm assuming this had to have been due to the export/import of the database (I used phpAdmin to do this), as this wasn't an issue previously on the old machine.

Can someone provide some assistance on how to clean up this field? What should the default values be?

Specifics: Eventum 1.7.1, PHP 4.4.0, Mysql 4.1.14, apache 2.0.55

Thanks!