joncas

Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • joncas
    Participant

    What worked for me is what I wrote above (post #871) is to edit the file located at /modules/invoices/save.php

    On line 71 (in my version),

    replace
    $_POST["unit_price$i"]

    with
    SiLocal::dbStd($_POST["unit_price$i"])

    (see enclosed image)

    Attachments:
    You must be logged in to view attached files.
    joncas
    Participant

    I’m glad someone else beside me has the same symptom!
    I still believe that the posted price string needs to be normalized with SiLocal::dbStd($_POST[“unit_price$i”]) for processing amounts with 4 or more digits.

    in reply to: performance with large datasets #907
    joncas
    Participant

    p.s.: I solved the currency error (it was due to an invoice preference using the € symbol instead of EUR.
    Opening the invoice list is indeed much faster than before: it now takes 8 seconds.
    Creating a new invoice still takes nearly 40 seconds.
    But even with the latest version of master_2019.2 in a clean install, the comma used as a thousands separator in the amount still gets passed on to the database insert query and causes the same error.

    in reply to: performance with large datasets #905
    joncas
    Participant

    Hello, and excuse the late answer (I had forgotten to tick the “Notify” box for this post, so I didn’t realize that you had responded).
    It seems a little faster, but I’ll have to try on the unix server, because in MAMP no invoices show in the list (opening the list pauses for several seconds, but none are displayed).
    The data.json file contains all the invoices (2.6 MB), but they are not rendered on screen due to an error in the javascript (see enclosed image), which may be due to running on MAMP on an Apple computer.
    I can create a new invoice, and all the customers and products show, but that part is still very slow which is inevitable if they all have to load into the selects.
    I’ll try to test this on the unix server over the weekend.

    Attachments:
    You must be logged in to view attached files.
    in reply to: three sql errors when upgrading from 2013.1.beta.8 #879
    joncas
    Participant

    One more patch that would be needed when upgrading older si databases is to add the password constraints to the si_system_defaults table:

    password_lower
    password_min_length
    password_number
    password_special
    password_upper

    Otherwise the validation pattern in the user edit form doesn’t accept any password changes.
    Enclosed is the patch update display that showed when first opening the old database with Master_2019.2
    After applying them all, the password constraints were still missing in the si_system_defaults table.

    joncas
    Participant

    Hello,

    It may depend on the localization settings? This site is set to British English, so numbers display with a comma as thousands separator (see enclosed screenshot), and apparently this is passed on in the POST arguments because the sql error was complaining that this was being used in the insert command.
    In your code the “edit” function already did use SiLocal::dbStd to filter that out, so it would seem logical that the insert should, too, no?

    Enclosed also the phpinfo: this is a dedicated Linux server running Ubuntu 18.04

    Attachments:
    You must be logged in to view attached files.
    joncas
    Participant

    p.s.: Searching the files listed in the error log, it looks like the patch would be on in /modules/invoices/save.php
    the “insert” case on line 71, one should use SiLocal::dbStd($_POST[“unit_price$i”]) instead of the unmodified $_POST[“unit_price$i”] (as the “edit” case does)

    • This reply was modified 6 months, 1 week ago by joncas.
Viewing 7 posts - 1 through 7 (of 7 total)