Forum OpenACS Q&A: ERROR: parser: parse erroro at or near ")"

1: ERROR: parser: parse erroro at or near ")"

Posted by Hans Gaasenbeek on 07/12/01 11:20 PM

Hello guys! (are there any women out there btw?)...

After a not-so-elegant restart of PostgreSQL, in our instance of OpenAcs (3.2.5) both /intranet/index.tcl and /pvt/home.tcl produce 'server errors'. In other words, these pages cannot be viewed. Invariably, PostgreSQL produces the 'parser error' mentioned above. Is the database damaged? What can I do about it?

Thank you for any answers!

2: Response to ERROR: parser: parse erroro at or near ")" (response to 1)

Posted by Hans Gaasenbeek on 07/13/01 12:54 AM

Should be "parse error" actually.

3: Response to ERROR: parser: parse erroro at or near ")" (response to 1)

Posted by Don Baccus on 07/13/01 01:38 AM

That's very strange. Does the exact same query fail in PSQL as well?

A quick guess - some function(s) disappeared due to whatever you did to restart PostgreSQL. This is nothing but a guess, however ...

4: Response to ERROR: parser: parse erroro at or near ")" (response to 1)

Posted by Hans Gaasenbeek on 07/13/01 02:25 PM

The situation is as follows: Until now, I restarted the whole server with "reboot". (I had not even read about the clean way to stop or restart PostgreSQL). At some unlucky moment, I decided to change nsd.tcl so that passwords would be encrypted. I thought that in order to make the change work I should restart both AOls and Postgres, and so I did... using Ctrl-C in both virtual consoles where these were running, and restarting. From that moment on, nobody was able to access their homepages or intranet, or even to log in. It appeared that passwords were changed, and after asking the server to email those it was able to log in again, but homepages and all intranet pages (i.e. all pages with /intranet/....) were inaccessible.

Don, your suggestion (and question) is helpful but I do not know how to find out which QUERY it is that PG has problems with.

To ask how I could get to know this is, IMO, something to be cathegorized as a *RTFM*-question (I should find out for myself, taking a bit of time), but my friends here insist I should ask. (I'm afraid a couple more of those questions would damage my (not too clever) reputation even more

Still, we have no time to lose now so I ask anyone with a lot of compassion to tell me how to find out what kind of query it is that causes the above error message and what to do about it.

5: Response to ERROR: parser: parse erroro at or near ")" (response to 1)

Posted by Dave Bauer on 07/13/01 03:18 PM

Check you server.tcl startp file in that database pools for this:

verbose on
logsqlerrors on
extendedtableinfo on

Make sure these parameters are set like this for all 3 database pools. This will hopefully log the information you need to track down the query that is causing the error.

6: Response to ERROR: parser: parse erroro at or near ")" (response to 1)

Posted by Roberto Mello on 07/13/01 04:21 PM

Hans,

I hope that by now you have learned the correct way to start/stop AOLserver and PostgreSQL. If not, please take a look at their documentation. It's not much of a problem to AOLserver, but it is a BIG problem for PostgreSQL.

When you changed your .tcl file to store encrypted passwords in the database, you made the software also look for encrypted passwords in the database.

Your current users had their passwords stored in clear text, so when they try to login, OpenACS grabs their passwords from the DB "thinking" they are encrypted. Since they are not, the login fails.

If you really want to use encrypted passwords, you'll have to convert all your user's passwords to the encrypted form. Or delete all your users, and ask them to re-create their login (in which case their passwords would be store encrypted).

A quick solution is change your servicename.tcl to go back to plain text passwords.

7: Response to ERROR: parser: parse erroro at or near ")" (response to 1)

Posted by Hans Gaasenbeek on 07/19/01 11:01 AM

Well, I did that, but the pages concerned don't show up. Strangely,
both /pvt/home and /intranet pages are still inaccessible (server
error). For the moment, we do without them.