xTuple.com xTupleU Blog & News Customer Support

Upgrade 4.10.1 to 4.11.0 - error message

I get the following error message when I try to upgrade V 4.10.1 to V 4.11.0

ERROR: SyntaxError: Unexpected token ILLEGAL
DETAIL: js_init() LINE 1:
(XX000)
QPSQL: Unable to create query

Any help would be much appreciated

I have noticed a similar problem. Try to re-open the update package you are trying to apply and the start the update. For whatever reason, the update seems to proceed the second time around…

And if Anil’s suggestion does not work, try running the Updater on either a Linux box or Mac. This problem has so far appeared on Windows machines. The next release of the Updater (beta coming soon) should fix this.

Gil

Neither of these things worked. I tried running the updater 2.4 x 3 times - all 3 times from a linux machine

Maybe I should try a windows machine?

Nope. Similar error message in windows.

I was able to get it to work with the linux client, if I run it once, then re-open the upgrade file (without going in and out of the updater again). The second time it competed.

I will try the 2.5 beta also, thanks

Did the 2.5 beta fix the problem?

HI

This is manufacturing edition @ 4.10.0 trying to upgrade to 4.11.0
Postgres 9.3, PGAdmin 1.22, windows server 2008R2 64 bit

I applied xtdash to 4.10.0 and used both updaters 2.4 and 2.5, get the following error:
ERROR: SyntaxError: Unexpected identifier
DETAIL: js_init() LINE 4: roleNames.push(dataSourcePrivName);
(XX000)
QPSQL: Unable to create query

executed the xTU link for error fix in this post above, still the same results

I started again with a base of 4.8.1 went up to 4.10.0, this time did not update the xtdash
executed the xTU sql, checked for plv8 and uuid-ossp, used both the updaters more than twice each and the erro has slightly changed to:
ERROR: SyntaxError: Unexpected identifier
DETAIL: js_init() LINE 1: a negative integer, this function finds the appropriate
(XX000)
QPSQL: Unable to create query

I am not sure if xtDash has caused the error signal to be different

please help
Thanks

Sajeev,

It sounds like the xt.js_init() function has gotten corrupted or some code is running it at the wrong time. Please run the following query to do a sanity check and let us know the results:

SELECT length(prosrc),
       substring(prosrc for 200) AS front,
       substring(prosrc from (length(prosrc) - 200)) AS back
  FROM pg_proc
 WHERE proname = 'js_init';

Gil

I have the same problem the sanity text returns )) {

Gil,

I am using postgresql 9.3 over windows.

Gil,

I restored the backup over my network’s server xtuple server (old admin version). And run the upgrade with no problem. The only problem is (this is over postbooks commercial) that after installing the dashboards I get a websocket error.

Regards

Alfredo’s results indicate that the xt.js_init() function has indeed been corrupted. The output should look something like this:

 length |                        front                        |                                     back                                     
--------+-----------------------------------------------------+------------------------------------------------------------------------------
  31692 |                                                    +| ar i = 0; i < res.length; i++) {                                            +
        |                                                    +|         if(DEBUG) XT.debug('loading javascript for type->', res[i].js_type);+
        | return (function () {                              +|                                                                             +
        |                                                    +|         eval(res[i].javascript);                                            +
        |   if (plv8.XT && !initialize && !debug) {          +|       }                                                                     +
        |     return;                                        +|     }                                                                       +
        |   }                                                +|     plv8.__initialized = true;                                              +
        |                                                    +|   }                                                                         +
        |   DEBUG = debug ? debug : false;                   +|                                                                             +
        |                                                    +| }());                                                                       +
        |   if (plv8.version < '1.3.0'){                     +|                                                                             +
        |     plv8.elog(ERROR, 'plv8 version 1.3.0 or greater | 
(1 row)

To fix it, load the right version of the function into your database. Here’s one way to do that:

  • look at the function definition on github
  • select the right tag to match your database version
    • click on the BRANCH combobox
    • click on the Tags tab
    • scroll down to the tag that matches your database version and click on it
  • click the RAW button
  • save the raw version of the file, e.g. File > Save As…
  • run that file with psql or pgAdmin or the MetaSQL editor.

As always, test this with a staged database before running in production.

Gil

Gil,

I am not sure why can that be because I did re created the function and anyway I think that do not explain why when I made a backup and brought it down to my server and restore it worked fine.

T add another weird thing, the websocket error do not show up when I backed up the database, uploaded to customer’s server and restored there. The restored database worked fine with no error.

Alfredo

Alfredo, Did you have more than one xTuple open when you got the websocket error?

Phil,

Yes, I was the only user and I logout and login like 5 to 10 times and everytime I got the error. I made the backup and upload to customer’s server. In the meantime I disabled the package in my copy to stop the error but when I restored in customer server and login to disable the package it login with no error so I left it running. It is an upgrade pilot but I don’t want to pass thru the same pain on the upgrade day.

Alfredo

Alfredo,

The websocket error is unrelated to the xt.js_init() problem. As Phil implied, the websocket error occurs when more than one xTuple ERP desktop client is open at the same time on a single machine (laptop, desktop, whatever). It is a conflict between two clients trying to run the dashboards extension at the same time. If the clients are running on different machines then there is no conflict.

I don’t know how the xt.js_init() function is getting messed up. All I can say is that )) { is the wrong output for the sanity check.

Gil

You can bump the websocket up a little and try that if you have more than one database you are logging into:

Gil,
Has this been fixed? I get the same issue on a Windows server when updating from 4.10.1 to 4.11.0

Gerhard,

We cannot be sure we have fixed the problem (presumably you’re referring to the initial problem Fred brought up). We’ve made a number of changes that seem to work, only to have someone outside our walls see the problem after we’ve made the changes. To summarize, here are the workarounds that have helped at one point or another:

  • Don’t quit the Updater if the upgrade fails. Just File > Open the upgrade package again and rerun it. [see Anil’s 1st reply]
  • Run the Updater from a machine not running Windows. [always works for me and some other people]
  • Reload xt.js_init() as described above. [only works if xt.js_init() has been corrupted]
  • Patch the .gz file [works for some people]:
    • copy the file to a temporary working directory

    • tar xf name_of_updater_package.gz

    • edit the files in the directory that is created by the tar command

    • look for non-ASCII characters in each file. Note that these files have between 7K and 333K lines. The most likely place to find one of these unexpected characters is just after a line that starts with this:

      – Script File Location:

If you find any non-ASCII characters and remove them:

  • rebundle the files: tar czf updater_package_revised.gz dirname
  • load the revised .gz with the Updater

I wish I could be more helpful but that’s all we know at this point.

Gil