RSS

LuxCal Forum

The place for questions, suggestions and news about the LuxCal Event Calendar

User:   Password:   Remember Me?   
LuxCal Forum / General / Support / Call to a member function query()
Posted:  06 Nov 2016 20:07
Hi there,
Many thanks again for your continued support of this program, it's really great!

I have run into a problem, when running lcalcron the browser throws up the following message


Fatal error: Call to a member function query() on a non-object in C:xampphtdocsdiarycommontoolboxd.php on line 49

Scratching my head a bit, looked at line 49 but does not seem to be anything particular. I have re-copied fresh copies of these files in with no avail. scratching my head a little bit now as I'm not up to speed with coding! :(
Posted:  06 Nov 2016 21:36
The oddest thing is that I reloaded a backup of the calendar files from a few weeks ago and it worked, when i went back to my current install the problem came back. hurrm.
Posted:  07 Nov 2016 00:08   Last Edited By: Roel B.
Hmm, strange . . .
It can't be toolboxd.php. This file hasn't changed since a very long time.

The error means that on line 49 of toolboxd.php . . .

$stH = $dbH->query($query);

$dbH (which is the database handle) is not a database handle (it may be undefined, or just "false" because of an error) , and this means that connecting to the database failed.
When running lcalcron.php, connecting to the database is done on line 140 (MySQL version) or line 161 (SQLite version) of the file lcalcron.php.

I assume you are using the MySQL version of the calendar:
Could you run the file lcalcron.php once manually (just open the file in your browser) and see if you get a "Could not connect to calendar database" error message directly in the browser and let me know the outcome.
Roel
Posted:  07 Nov 2016 00:08
Update**

Line 49 "        $stH = $dbH->query($query);"
I have some funny feeling that the calendar ID is not getting set right, but have not managed to find out where anything is stored except for in lcconfig which only mentions database specific information.
Posted:  07 Nov 2016 00:20   Last Edited By: Roel B.
ohmy our posts crossed.

Yes, I agree and I think you are close.
There is either no connection to the database made, or the calendar ID is not set. I think there is no connection, because if the calendar ID (stored in $calID) is not set or wrong, it would result in a SQL error (on line 49 of toolboxd.php).

It works as follows:
- In lcalcron.php, on line 140 a connection is made with the database
- In the foreach loop, on line 159, all calendars (if you have several in use) are processed. If you have only one calendar in use, it will process that one calendar.
- On line 163 $calID is set to the ID of the processed calendar (in your case this is probably "mycal")
- In toolboxd.php the calendar ID (i.e. $calID) is added to the SQL query on line 47.

Roel
Posted:  10 Nov 2016 00:18   Last Edited By: Speakersrock
hahaa my bad, getting a bit trigger happy thump_up

Hi Roel, Thanks so much for your thoughts. The error I wrote about is the one that gets displayed in any internet browser. Seems odd that the error shown is not one of the ones scripted into lcalcron though?

Thanks for explaining the process too, helped me to get my head around it, but alas found no explanations. To be honest I cannot even find where in the database or calendar files the CALID are saved. I have used the tools to delete and create a new calendar but this achieves precisely nothing except for deleting all my data.

Try triggering the Cron job if you'd like - http://heavens-end.co.uk:83/diary/lcalcron.php
The calendar can be found at the same address.

http://heavens-end.co.uk/share/phpmyadmin.jpg
Posted:  04 Dec 2016 02:40
Roel,

Many thanks for all your time with this. After finally taking the time this week to upgrade to newer server OS, PHP, Apache e.t.c and still experiencing problems I realised it was defiantly going to be something as you described, cannot connect to database.

Turns out, it was a classic ID10T error.

I had the 'Periodic functions' set to local and within the cron file itself I had commented out the 'security check' section as instructed in historic versions of the calendar. I guess this was just ingrained into me and I must have done it without even thinking upon last upgrade or something. So after alot of head scratching, all sorted! I would say perhaps this will help someone else - but doubtful they will get into the same scenario.

New 4.5.1. update looks great, can't wait to have a look through it after I catch up on all the events we missed!! cool