Hi,
TimeTrex was installed and working fine for the last one and half years. Yesterday got a mail stating a new version was released. Downloaded. Luckily, took a db backup. Ran the installer, warned to take a backup since I upgraded. Then selected, advanced install, since I have changed the Apache port. Halfway through got a warning that user cannot be created, clicked ok, install continued, then before finishing, got another warning, same from postgresql.
After which, install completed, asked to open browser, did, checked the requisites, all fine. When coming to db configuration, did a test connection, failed. Tried to change all user details, referred php.ini file, did all, but culdn succeed.
Uninstalled. Removed the directory manually, restarted server. Started the install, did the same steps as above. Now, started the browser as prompted, in the requisite, cache, log and storage showed warning.
After search thru this forum, checked the .ini file and all the values/path referred to linux environment. Strange!!!
Changed everything, re-check, all ok.
Next page, db config, same error.
Damn!!
Uninstall, installed older version, during install, asked account name for postgre, given all, finished install, no postgre directory inside Timetrex.
Again strange.
uninstall, tried again, now in the pg config box, i created the user manually and provided the detail. same. Again damn.
uninstall, tried 3.0, same error. So tried to create user in PG manually, gave a error, server not listening and to check the port number, it was wrong, corrected it in .conf file, restarted the pg service, now asking for postgres password. What is the password? I have not setup anything.
PG service is running fine and pg_hba file is allowing all connections from localhost and now added IP addresses too accor to our network.
Kindly help.
Sorry for the loong post.
Edit: Server details,
OS - Win 2003 SP2
Database - PostgreSQL
TT Version - 3.0 latest
Upgrade to 3.0.0 help - Windows
I had a similar experience.
I started out with version 2.2.28, and was thrilled when I saw the announcements for 3.0.0 release candidates.
I had trouble doing the upgrade to RC2, RC3, and RC4.
Each time, something else would go wrong, and I ended up having to restore from my backup.
Yesterday's install was the worst.
I spent the entire day trying to get the system to work again. It would get stuck at "waiting for database to start. then at 'waiting for Apache to stop" then I would get an error that my time zone uses leap seconds.
No matter what I tried, I got some sort of error.
Luckily, I discovered that if I stop the services, and back up the ENTIRE c:\timetrex folder, I can copy it back in with no problems to restore.
I did that well over a dozen times yesterday.
Finally, I decided to try downloading again.
Strangely, the file date and time on Sourceforge was different last night than it was yesterday morning when I originally downloaded. And the size of the file was different (by only a few bytes).
I did a complete uninstall, and then a fresh install (using the new installer). It worked!
I was then able to restore my old database (using the restore_database.bat file), and I'm back up and running.
I'm hoping they figure out what's causing these installer issues for the next version.
I started out with version 2.2.28, and was thrilled when I saw the announcements for 3.0.0 release candidates.
I had trouble doing the upgrade to RC2, RC3, and RC4.
Each time, something else would go wrong, and I ended up having to restore from my backup.
Yesterday's install was the worst.
I spent the entire day trying to get the system to work again. It would get stuck at "waiting for database to start. then at 'waiting for Apache to stop" then I would get an error that my time zone uses leap seconds.
No matter what I tried, I got some sort of error.
Luckily, I discovered that if I stop the services, and back up the ENTIRE c:\timetrex folder, I can copy it back in with no problems to restore.
I did that well over a dozen times yesterday.
Finally, I decided to try downloading again.
Strangely, the file date and time on Sourceforge was different last night than it was yesterday morning when I originally downloaded. And the size of the file was different (by only a few bytes).
I did a complete uninstall, and then a fresh install (using the new installer). It worked!
I was then able to restore my old database (using the restore_database.bat file), and I'm back up and running.
I'm hoping they figure out what's causing these installer issues for the next version.
hi,
thnx for shring your experience and a possible solution. I too doubted that the installer must be a problem, thats the reason I have mentioned in my post that after install, linux environment path is setup in .ini file.
Coming to your input, I will download the file again, uninstall, delete the folder manually, restart my server and install.
Once the install is succeeded, it will ask to open the browser. Should we do it?
If yes, for how much screens should we proceed? cos, shaun has replied in some of the thread that we should proceed until u get the company info and admin details screen.
How did you proceed? A step by step info would be great.
T i A
thnx for shring your experience and a possible solution. I too doubted that the installer must be a problem, thats the reason I have mentioned in my post that after install, linux environment path is setup in .ini file.
Coming to your input, I will download the file again, uninstall, delete the folder manually, restart my server and install.
Once the install is succeeded, it will ask to open the browser. Should we do it?
If yes, for how much screens should we proceed? cos, shaun has replied in some of the thread that we should proceed until u get the company info and admin details screen.
How did you proceed? A step by step info would be great.
T i A
To be honest, I don't remember exactly. I went through the process so many times yesterday, that I don't know 100% what worked.
However, here's what I THINK I did (I'm not responsible if this doesn't work, though):
1) Verified that I had a WORKING backup (copy of ENTIRE original C:\timetrex folder), as well as a backup file (in the .SQL format) of the database itself. This is something I plan to do before ANY future upgrades. Only takes a minute to do, but it can save HOURS of frustration if you need to back out an upgrade.
2) Uninstalled completely. This removed the entire C:\timetrex folder, and both the Apache and Postgresql services as well.
3) Installed using the new installer. I continued through the company information, and admin account/password, all the way through, including logging in afterward. (I used dummy information, though).
(here's where my memory is a bit fuzzy - this may not be 100% accurate)
4) I used the NEW restore_database.bat to restore the backup .SQL file.
5) I stopped the TimeTrex services.
6) I copied the OLD restore_database.bat, backup_database.bat, and timetrex.ini.php files from my backup folder into the "live" folder. (I renamed the ones I was replacing, just in case)
7) In the timetrex.ini.php file, I changed the "installer_enabled = FALSE" line to read "installer_enabled = TRUE"
I restarted the TimeTrex services
9) I went back to the installer interface (via the shortcut from the Start Menu), and completed the database restore/upgrade
10) I logged in, and verified that my data was restored and working
If anyone wants to verify these steps, and/or make any necessary corrections, it might be helpful for others.
However, here's what I THINK I did (I'm not responsible if this doesn't work, though):
1) Verified that I had a WORKING backup (copy of ENTIRE original C:\timetrex folder), as well as a backup file (in the .SQL format) of the database itself. This is something I plan to do before ANY future upgrades. Only takes a minute to do, but it can save HOURS of frustration if you need to back out an upgrade.
2) Uninstalled completely. This removed the entire C:\timetrex folder, and both the Apache and Postgresql services as well.
3) Installed using the new installer. I continued through the company information, and admin account/password, all the way through, including logging in afterward. (I used dummy information, though).
(here's where my memory is a bit fuzzy - this may not be 100% accurate)
4) I used the NEW restore_database.bat to restore the backup .SQL file.
5) I stopped the TimeTrex services.
6) I copied the OLD restore_database.bat, backup_database.bat, and timetrex.ini.php files from my backup folder into the "live" folder. (I renamed the ones I was replacing, just in case)
7) In the timetrex.ini.php file, I changed the "installer_enabled = FALSE" line to read "installer_enabled = TRUE"
I restarted the TimeTrex services9) I went back to the installer interface (via the shortcut from the Start Menu), and completed the database restore/upgrade
10) I logged in, and verified that my data was restored and working
If anyone wants to verify these steps, and/or make any necessary corrections, it might be helpful for others.
Just to confirm there was a bug in the v3.0.0-final windows installer that would cause the timetrex.ini.php file to use Linux default values rather than Windows, however this should only happen during a fresh install, not an upgrade.
This was discovered and fixed within about 8 hours of the initial v3.0 release.
It is fine to copy the entire c:\timetrex directory as a backup, but make absolutely sure that the TimeTrex services (specifically the database) is shutdown before you do it. If its not the database has a very good chance of being corrupted. Just because you copy the directory back and the database starts up does not mean that data wasn't corrupted and possibly lost either.
The reason is simple, if your database is 1GB in size and the copy takes 10 seconds to complete, if 5 seconds in someone logs into TimeTrex, or even if the maintenance job starts in the background, it could update the database in mid-copy resulting in a corrupt database, but you may not be aware of this for several months when you finally try to access the corrupted area and everything comes to a halt.
You should always have a .SQL backup as well, because that is guaranteed to be consistent and non-corrupt and you do not need to shutdown any services to run the backup_database.bat file.
One last thing to note, it is a good idea to have a copy of your entire TimeTrex directory along with a .SQL backup as the timetrex.ini.php contains encryption keys for the database, and the storage directory can hold other data outside the database too.
The odd thing about your issue is that you were doing an upgrade but the installer attempted to touch PostgreSQL, which it should never do during an upgrade. This could be related to the advance install options/changes you made though, I will pass this on to our developers to look into in more detail.
This was discovered and fixed within about 8 hours of the initial v3.0 release.
It is fine to copy the entire c:\timetrex directory as a backup, but make absolutely sure that the TimeTrex services (specifically the database) is shutdown before you do it. If its not the database has a very good chance of being corrupted. Just because you copy the directory back and the database starts up does not mean that data wasn't corrupted and possibly lost either.
The reason is simple, if your database is 1GB in size and the copy takes 10 seconds to complete, if 5 seconds in someone logs into TimeTrex, or even if the maintenance job starts in the background, it could update the database in mid-copy resulting in a corrupt database, but you may not be aware of this for several months when you finally try to access the corrupted area and everything comes to a halt.
You should always have a .SQL backup as well, because that is guaranteed to be consistent and non-corrupt and you do not need to shutdown any services to run the backup_database.bat file.
One last thing to note, it is a good idea to have a copy of your entire TimeTrex directory along with a .SQL backup as the timetrex.ini.php contains encryption keys for the database, and the storage directory can hold other data outside the database too.
The odd thing about your issue is that you were doing an upgrade but the installer attempted to touch PostgreSQL, which it should never do during an upgrade. This could be related to the advance install options/changes you made though, I will pass this on to our developers to look into in more detail.
Thanks for confirming that I was on the right track.
Yes, I made sure to shut down the services before I did any copying of the folders.
I had numerous issues trying to do the upgrade, and I would chalk that up to the buggy installer, but even with the new installer, I still got stuck waiting for Apache to shut down, even though the service was already stopped.
With the RC installs, I had the problem of it "waiting for database to start" and never getting past there.
I didn't try turning on the debug mode for the installer. I suppose I can try that before the next version upgrade.
Yes, I made sure to shut down the services before I did any copying of the folders.
I had numerous issues trying to do the upgrade, and I would chalk that up to the buggy installer, but even with the new installer, I still got stuck waiting for Apache to shut down, even though the service was already stopped.
With the RC installs, I had the problem of it "waiting for database to start" and never getting past there.
I didn't try turning on the debug mode for the installer. I suppose I can try that before the next version upgrade.
It is possible for the installer to get into trouble waiting for services to shutdown if the services are in use, or some connections are left active.
The way the installer knows this has happened is by checking to make sure the ports (Apache and PostgreSQL) are no longer listening, and we have seen cases where for some reason Apache has processes lying around in several states, either stuck listening on the port, or still running and not listening on the port, either case can obviously cause problems.
What can sometimes help is rebooting the server before attempting the upgrade, this will ensure that any zombie processes are no longer running and there should be no problem stopping the services.
Unfortunately this appears to be more of an Apache on certain Windows computer issue, I'm not sure there is much our installer can do short of trying to forcefully kill Apache processes, but that can lead to other nasty issues too.
The way the installer knows this has happened is by checking to make sure the ports (Apache and PostgreSQL) are no longer listening, and we have seen cases where for some reason Apache has processes lying around in several states, either stuck listening on the port, or still running and not listening on the port, either case can obviously cause problems.
What can sometimes help is rebooting the server before attempting the upgrade, this will ensure that any zombie processes are no longer running and there should be no problem stopping the services.
Unfortunately this appears to be more of an Apache on certain Windows computer issue, I'm not sure there is much our installer can do short of trying to forcefully kill Apache processes, but that can lead to other nasty issues too.
@noamparn
first try, following the exact steps of yours failed
After install and initial login, stopped all services and checked for backup, restore and .ini in the backup. .ini present, backup present, missing restore. So, copied the .ini alone and changed false to true for installer.
Started the services, did a restore, success. This restore is the new one.
Started the installer thru start menu, now when coming to db config, old db pwd was present in the pwd field, tested the connection, failed.
So, changed old to new in .ini and install page, tested, success. Now the db was upgraded, tried to login, no old user details worked. Only the new one worked, no old data present.
Solution(may be)
Uninstall, re-install. When coming to db config, will provide the old pwd. Once the db test is done, will close the browser.
Do a restore, once done, copy the old .ini and change false to true.
Will try to start install and check what is happening.
One more doubt is, what about the salt?
Should it be the old or new?
I believe, shaun would be able to guide me from here or even noamparn.
first try, following the exact steps of yours failed
After install and initial login, stopped all services and checked for backup, restore and .ini in the backup. .ini present, backup present, missing restore. So, copied the .ini alone and changed false to true for installer.
Started the services, did a restore, success. This restore is the new one.
Started the installer thru start menu, now when coming to db config, old db pwd was present in the pwd field, tested the connection, failed.
So, changed old to new in .ini and install page, tested, success. Now the db was upgraded, tried to login, no old user details worked. Only the new one worked, no old data present.
Solution(may be)
Uninstall, re-install. When coming to db config, will provide the old pwd. Once the db test is done, will close the browser.
Do a restore, once done, copy the old .ini and change false to true.
Will try to start install and check what is happening.
One more doubt is, what about the salt?
Should it be the old or new?
I believe, shaun would be able to guide me from here or even noamparn.
Last edited by dre@ms on Fri Oct 23, 2009 3:38 am, edited 1 time in total.
New Update 1,
Installed afresh, continued till the end. Restored the old db. Restore returned no error.
Modified .ini file, upgraded the db, tried to login, failed. Newly created login works but fresh.
New Update 2,
Installed afresh, closed browser when showed company info.
Restored the db, modified .ini, upgraded the db, tried to login, failed.
Checked the db after restore, empty.
Tried in my lappy wit Win 7. After install, and license acceptance, directly went to 3rd page, asking company info, left it untouched.
Restored the db, checked the db for data, still empty.
Now went back to company info page, filled it, created user. Checked the db, data is in.
What is the problem?
Why restoring doesnt work? I can see table created message, create index message, insert 0 1, grant, etc.
But no data is inserted.
Please help!!!
Installed afresh, continued till the end. Restored the old db. Restore returned no error.
Modified .ini file, upgraded the db, tried to login, failed. Newly created login works but fresh.
New Update 2,
Installed afresh, closed browser when showed company info.
Restored the db, modified .ini, upgraded the db, tried to login, failed.
Checked the db after restore, empty.
Tried in my lappy wit Win 7. After install, and license acceptance, directly went to 3rd page, asking company info, left it untouched.
Restored the db, checked the db for data, still empty.
Now went back to company info page, filled it, created user. Checked the db, data is in.
What is the problem?
Why restoring doesnt work? I can see table created message, create index message, insert 0 1, grant, etc.
But no data is inserted.
Please help!!!
Which version of TimeTrex was your backup taken with?
Can you copy and paste the first 100-200 lines of the .SQL file here?
Its possible that if your original backup script was old enough that the backup file isn't a "complete" backup in the sense that it will create the database and handle everything from scratch. It may just import the data into whatever database you connect too, which the new restore script connects to "template1" database. (which is required when using .SQL files from the new backup script).
I'm not sure how you are connecting to the database to see if data exists, but if you are using PSQL to do it, try connecting to the "template1" database and see if your data is there instead. If it is, its a simple matter of changing the new restore script to work around this issue. You definitely DO NOT want to use any data from the template1 database, as it could get wiped out on a whim.
Can you copy and paste the first 100-200 lines of the .SQL file here?
Its possible that if your original backup script was old enough that the backup file isn't a "complete" backup in the sense that it will create the database and handle everything from scratch. It may just import the data into whatever database you connect too, which the new restore script connects to "template1" database. (which is required when using .SQL files from the new backup script).
I'm not sure how you are connecting to the database to see if data exists, but if you are using PSQL to do it, try connecting to the "template1" database and see if your data is there instead. If it is, its a simple matter of changing the new restore script to work around this issue. You definitely DO NOT want to use any data from the template1 database, as it could get wiped out on a whim.
After more extensive search I guess the problem with restore is the version. Anyways, find the details below,shaunw wrote:Which version of TimeTrex was your backup taken with?
Can you copy and paste the first 100-200 lines of the .SQL file here?
Its possible that if your original backup script was old enough that the backup file isn't a "complete" backup in the sense that it will create the database and handle everything from scratch. It may just import the data into whatever database you connect too, which the new restore script connects to "template1" database. (which is required when using .SQL files from the new backup script).
I'm not sure how you are connecting to the database to see if data exists, but if you are using PSQL to do it, try connecting to the "template1" database and see if your data is there instead. If it is, its a simple matter of changing the new restore script to work around this issue. You definitely DO NOT want to use any data from the template1 database, as it could get wiped out on a whim.
I believe I downloaded the setup last december. The exe is having a version 1.0.0.0. When I tried re-installing the same version, restore.bat file is missing.
I use Navicat to check the table and data. Once I connect to PG, I can see 2 schema postgres and timetrex.
Under timetrex 99 tables are present. None of the table contains any data after restore.
Please find the first 200 lines from my sql file.
If any more details needed, let me know.--
-- PostgreSQL database dump
--
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
--
-- Name: SCHEMA public; Type: COMMENT; Schema: -; Owner: postgres
--
COMMENT ON SCHEMA public IS 'Standard public schema';
--
-- Name: plpgsql; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: postgres
--
CREATE PROCEDURAL LANGUAGE plpgsql;
SET search_path = public, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- Name: absence_policy; Type: TABLE; Schema: public; Owner: timetrex; Tablespace:
--
CREATE TABLE absence_policy (
id integer NOT NULL,
company_id integer NOT NULL,
name character varying NOT NULL,
type_id integer NOT NULL,
over_time smallint DEFAULT 0 NOT NULL,
accrual_policy_id integer,
premium_policy_id integer,
pay_stub_entry_account_id integer,
created_date integer,
created_by integer,
updated_date integer,
updated_by integer,
deleted_date integer,
deleted_by integer,
deleted smallint DEFAULT 0 NOT NULL
);
ALTER TABLE public.absence_policy OWNER TO timetrex;
--
-- Name: absence_policy_id_seq; Type: SEQUENCE; Schema: public; Owner: timetrex
--
CREATE SEQUENCE absence_policy_id_seq
START WITH 1
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
ALTER TABLE public.absence_policy_id_seq OWNER TO timetrex;
--
-- Name: absence_policy_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: timetrex
--
ALTER SEQUENCE absence_policy_id_seq OWNED BY absence_policy.id;
--
-- Name: absence_policy_id_seq; Type: SEQUENCE SET; Schema: public; Owner: timetrex
--
SELECT pg_catalog.setval('absence_policy_id_seq', 1, false);
--
-- Name: accrual; Type: TABLE; Schema: public; Owner: timetrex; Tablespace:
--
CREATE TABLE accrual (
id integer NOT NULL,
user_id integer NOT NULL,
accrual_policy_id integer NOT NULL,
type_id integer NOT NULL,
user_date_total_id integer,
time_stamp timestamp with time zone NOT NULL,
amount numeric DEFAULT 0 NOT NULL,
created_date integer,
created_by integer,
updated_date integer,
updated_by integer,
deleted_date integer,
deleted_by integer,
deleted smallint DEFAULT 0 NOT NULL
);
ALTER TABLE public.accrual OWNER TO timetrex;
--
-- Name: accrual_balance; Type: TABLE; Schema: public; Owner: timetrex; Tablespace:
--
CREATE TABLE accrual_balance (
id integer NOT NULL,
user_id integer NOT NULL,
accrual_policy_id integer NOT NULL,
balance numeric DEFAULT 0 NOT NULL,
banked_ytd integer DEFAULT 0 NOT NULL,
used_ytd integer DEFAULT 0 NOT NULL,
awarded_ytd integer DEFAULT 0 NOT NULL,
created_date integer,
deleted smallint DEFAULT 0 NOT NULL
);
ALTER TABLE public.accrual_balance OWNER TO timetrex;
--
-- Name: accrual_balance_id_seq; Type: SEQUENCE; Schema: public; Owner: timetrex
--
CREATE SEQUENCE accrual_balance_id_seq
START WITH 1
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
ALTER TABLE public.accrual_balance_id_seq OWNER TO timetrex;
--
-- Name: accrual_balance_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: timetrex
--
ALTER SEQUENCE accrual_balance_id_seq OWNED BY accrual_balance.id;
--
-- Name: accrual_balance_id_seq; Type: SEQUENCE SET; Schema: public; Owner: timetrex
--
SELECT pg_catalog.setval('accrual_balance_id_seq', 1, false);
--
-- Name: accrual_id_seq; Type: SEQUENCE; Schema: public; Owner: timetrex
--
CREATE SEQUENCE accrual_id_seq
START WITH 1
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
ALTER TABLE public.accrual_id_seq OWNER TO timetrex;
--
-- Name: accrual_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: timetrex
--
ALTER SEQUENCE accrual_id_seq OWNED BY accrual.id;
--
-- Name: accrual_id_seq; Type: SEQUENCE SET; Schema: public; Owner: timetrex
--
SELECT pg_catalog.setval('accrual_id_seq', 1, false);
--
-- Name: accrual_policy; Type: TABLE; Schema: public; Owner: timetrex; Tablespace:
--
CREATE TABLE accrual_policy (
id integer NOT NULL,
company_id integer NOT NULL,
name character varying NOT NULL,
type_id integer NOT NULL,
minimum_time integer,
maximum_time integer,
created_date integer,
created_by integer,
updated_date integer,
updated_by integer,
deleted_date integer,
deleted_by integer,
deleted smallint DEFAULT 0 NOT NULL,
apply_frequency_id smallint,
apply_frequency_month smallint,
apply_frequency_day_of_month smallint,
apply_frequency_day_of_week smallint,
milestone_rollover_hire_date smallint,
milestone_rollover_month smallint,
milestone_rollover_day_of_month smallint,
minimum_employed_days integer,
minimum_employed_days_catchup smallint,
enable_pay_stub_balance_display smallint DEFAULT 0 NOT NULL
);
Yup, its an old style .SQL file, as it doesn't have any connection strings at the top, so its designed to be restored into a specific database, where new style .SQL files are designed to be slightly more automated.
Try this procedure:
1. Uninstall TimeTrex completely, delete the TimeTrex directory.
2. Install v3.0 fresh, when it asks to launch the web browser, don't bother, you don't want to initialize the database or create a company at all.
3. You can confirm that the "timetrex" database does exist and is empty if you want, I don't see any reason why it wouldn't.
4. Modify the new restore_database.bat file, replace "template1" with "timetrex" at the end of the command. This is the key step, because you are using the old style .SQL file, you need to force the restore to dump the .SQL into the "timetrex" database, not "template1".
5. Once the restore is complete, copy the salt from the old timetrex.ini.php to the new one. You shouldn't need to copy the database password, since the old style .SQL file doesn't modify it. The salt will just allow the new install to decrypt the users passwords for logging in. You could use the "forgot password" functionality to work around this if you want.
6. Test to make sure everything is working, if it is, change the restore_database.bat back to normal, as any new .SQL dumps will need to connect to "template1" instead of "timetrex".
In theory that procedure should work.
Try this procedure:
1. Uninstall TimeTrex completely, delete the TimeTrex directory.
2. Install v3.0 fresh, when it asks to launch the web browser, don't bother, you don't want to initialize the database or create a company at all.
3. You can confirm that the "timetrex" database does exist and is empty if you want, I don't see any reason why it wouldn't.
4. Modify the new restore_database.bat file, replace "template1" with "timetrex" at the end of the command. This is the key step, because you are using the old style .SQL file, you need to force the restore to dump the .SQL into the "timetrex" database, not "template1".
5. Once the restore is complete, copy the salt from the old timetrex.ini.php to the new one. You shouldn't need to copy the database password, since the old style .SQL file doesn't modify it. The salt will just allow the new install to decrypt the users passwords for logging in. You could use the "forgot password" functionality to work around this if you want.
6. Test to make sure everything is working, if it is, change the restore_database.bat back to normal, as any new .SQL dumps will need to connect to "template1" instead of "timetrex".
In theory that procedure should work.
Silly question, but when you are doing the restore, and you running it from the command line, and using the name of the SQL file as the parameter?
The first time I tried a restore (after my failed upgrade to one of the RC versions), I didn't realize I was doing it wrong, which is why I wasn't getting the database to restore (granted, it was 3 AM, and my brain had shut down hours earlier).
When I followed the instructions more carefully the next morning, I was back up and running 10 minutes later.
The first time I tried a restore (after my failed upgrade to one of the RC versions), I didn't realize I was doing it wrong, which is why I wasn't getting the database to restore (granted, it was 3 AM, and my brain had shut down hours earlier).
When I followed the instructions more carefully the next morning, I was back up and running 10 minutes later.
@shaun
will try the steps and let u know..rather than trying it in my office server(only on monday), I will try it with my lappy and then do it in the server. I cant restart my server often, employee work is disturbed.
@noamparn
I too dont understand ur question, but I guess u r asking hw am I executing the restore.bat file, so here it is,
c:\program files\timetrex\restore_database.bat c:\timetrex.sql
will try the steps and let u know..rather than trying it in my office server(only on monday), I will try it with my lappy and then do it in the server. I cant restart my server often, employee work is disturbed.
@noamparn
I too dont understand ur question, but I guess u r asking hw am I executing the restore.bat file, so here it is,
c:\program files\timetrex\restore_database.bat c:\timetrex.sql
dre@ms -dre@ms wrote:@shaun
will try the steps and let u know..rather than trying it in my office server(only on monday), I will try it with my lappy and then do it in the server. I cant restart my server often, employee work is disturbed.
@noamparn
I too dont understand ur question, but I guess u r asking hw am I executing the restore.bat file, so here it is,
c:\program files\timetrex\restore_database.bat c:\timetrex.sql
Yes, I was asking if you were running the restore from the command prompt, or by double-clicking on it in Windows (which, I found out after trying it all night, is NOT the correct way to do it
). It looks to me like you are doing it right. The only thing I can think of is that perhaps the c:\timetrex.sql file you are restoring is not the correct one. (I made that mistake, too - TimeTrex had run a backup of the new database, and overwrote the backup of my old one. oops).
I'm certainly nothing close to an expert, so I'm going to defer to Shaun, and just sit back and watch.
Shaun - I'm going to assume that since I haven't seen widespread reports of problems installing or upgrading, that it works for most people, and I'm just messing it up each time somehow.
@shaun
thnx a ton m8..changing template to timetrex did the trick. Temporarily tried in my lappy, under XP since 7 showed some error.
Didn't open the browser, changed the word in .bat, restored, used navicat to check whether data is in, yeppies, all data in.
unfortunately dont hv the old ini in my lappy, so will try the same steps again tomorrow morning and check whether I am able to login successfully and view all data thru timetrex.
once again thanks for this great software and even greater support.
will keep u posted.
thnx a ton m8..changing template to timetrex did the trick. Temporarily tried in my lappy, under XP since 7 showed some error.
Didn't open the browser, changed the word in .bat, restored, used navicat to check whether data is in, yeppies, all data in.
unfortunately dont hv the old ini in my lappy, so will try the same steps again tomorrow morning and check whether I am able to login successfully and view all data thru timetrex.
once again thanks for this great software and even greater support.
will keep u posted.
Update..
We are back in business. Solution worked great. This is what I did,
1. Uninstalled. Not able to remove TT folder since some dll file of PG is been used. Uninstaller removed the services, so renamed the TT folder. (Not willing to restart the server)
2. Started the install, all went fine. When asked to open the browser, unchecked and clicked on finish.
3. Went into TT folder, copied the restore.bat to a diff location(cautious)
4. Edited the restore.bat file and removed template1 and put in timetrex
5. From command prompt fired the restore.bat. Completed successfully.
6. Copied the salt from my old php.ini and pasted it in the new php.ini(took a copy of new php.ini, cautious)
Note: New php.ini had a salt value of 0
7. Tried to directly login, got 500 internal server error.
8. From start menu, fired the installer, did all check, upgraded the db, then got a message successfully upgraded to 3.0.0
9. Clicked on login in the final page, gave my old login credentials.
BINGO!!!
Logged me in, and all data intact. Gracious!!!
Only thing, our company logo was missing, so uploaded and TT is back, up and running.
Thanks a ton to shaun and noamparn
Shaun, is the new version taking a backup of the db automatically? Cos, when I checked today morning, I could see many sql files inside the TT folder.
If yes, can the location be changed?
Thanks once again.
We are back in business. Solution worked great. This is what I did,
1. Uninstalled. Not able to remove TT folder since some dll file of PG is been used. Uninstaller removed the services, so renamed the TT folder. (Not willing to restart the server)
2. Started the install, all went fine. When asked to open the browser, unchecked and clicked on finish.
3. Went into TT folder, copied the restore.bat to a diff location(cautious)
4. Edited the restore.bat file and removed template1 and put in timetrex
5. From command prompt fired the restore.bat. Completed successfully.
6. Copied the salt from my old php.ini and pasted it in the new php.ini(took a copy of new php.ini, cautious)
Note: New php.ini had a salt value of 0
7. Tried to directly login, got 500 internal server error.
8. From start menu, fired the installer, did all check, upgraded the db, then got a message successfully upgraded to 3.0.0
9. Clicked on login in the final page, gave my old login credentials.
BINGO!!!
Logged me in, and all data intact. Gracious!!!
Only thing, our company logo was missing, so uploaded and TT is back, up and running.
Thanks a ton to shaun and noamparn
Shaun, is the new version taking a backup of the db automatically? Cos, when I checked today morning, I could see many sql files inside the TT folder.
If yes, can the location be changed?
Thanks once again.
dre@ms -
Shaun can verify, but mine started doing that with V3, as well. Mine defaulted to backing up very early every morning (1:55 am), saving teh .sql file to the root folder where TimeTrex is installed.
I moved mine by editing the location inside the backup_database.bat file, and that seems to have worked for the nightly backups.
--Noam
Shaun can verify, but mine started doing that with V3, as well. Mine defaulted to backing up very early every morning (1:55 am), saving teh .sql file to the root folder where TimeTrex is installed.
I moved mine by editing the location inside the backup_database.bat file, and that seems to have worked for the nightly backups.
--Noam
Upgrading to 3.0.1
From what I've read in the forums, it looks like we may see version 3.0.1 released as soon as next week.
Is there an upgrade function within the program, or will I have to download the installer, and run it manually?
Given the problems I've had going from version 2 through the version 3 release candidates and then to 3.0.0 final, I'm less than thrilled to try another upgrade install.
Is there an upgrade function within the program, or will I have to download the installer, and run it manually?
Given the problems I've had going from version 2 through the version 3 release candidates and then to 3.0.0 final, I'm less than thrilled to try another upgrade install.
The upgrade procedure is the exact same as the initial installation procedure, using the same type of file. So if you used the automated installer on windows initially, then you need to use the same automated installer to upgrade. The installer will detect an existing version of TimeTrex and automatically perform the upgrade.
There were a few bugs in the release candidate installers that unfortunately affected a small minority of our "early adopters", but those have since been fixed.
In 99% of the cases, the upgrade procedure takes about 5 minutes and completes without any problems.
In some cases we have seen issues stopping the TimeTrex services, but those are usually caused by stuck processes, which themselves can be caused by any number of reasons (bad hardware is a major contributor).
To avoid the stuck process issue, you could always reboot before the upgrade, or stop all TimeTrex services and check the Task Manager to ensure that they are in fact all stopped before performing the upgrade.
There were a few bugs in the release candidate installers that unfortunately affected a small minority of our "early adopters", but those have since been fixed.
In 99% of the cases, the upgrade procedure takes about 5 minutes and completes without any problems.
In some cases we have seen issues stopping the TimeTrex services, but those are usually caused by stuck processes, which themselves can be caused by any number of reasons (bad hardware is a major contributor).
To avoid the stuck process issue, you could always reboot before the upgrade, or stop all TimeTrex services and check the Task Manager to ensure that they are in fact all stopped before performing the upgrade.