Announcement

Collapse
No announcement yet.

[SOLVED] To be investigated by SC

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • [SOLVED] To be investigated by SC

    Originally posted by aducom View Post
    I can't answer that question fully. But regarding the last issue: if you know that you will have quotes in your string (and quotes can corrupt your sql statement) then i advise you to use the phpfunction addslashes in the onvalidate or onbeforeinsert/update. That will prevent your issue.

    regarding the sql datatypes, it's a reaction on inquiries to the database engine and I guess that odbc reports it as an array of char and db2 as a string. For php it's just a string. So I guess it's a difference like : myfield : char(x) to myfield varchar(x). I don't think this is a sc issue but a database driver issue.

    Thanks for you answer. I have spent some time in investigating this issue and I have found this fix.
    Hope this helps someone else out there using IBM DB2 like me.

    Background:

    SC automatically escapes the apostrophe, before any update and insert into the database, by changing the field value and duplicating the apostrophe.

    Example:
    Field {NAME} = "O'Neil" becomes {NAME} = "O''Neil" before being entered into the database.
    This is the correct way to escape the apostrophe in DB2 and SC+AdoDB works correctly so far.

    After the insert/update , the field {NAME} is restored back to a single apostrophe, by putting back the original form field value into the field variable.

    You can see how this mechanism works in details by playing with OnBeforeUpdate and OnAfterUpdate events, and by echoing, on each event, the value for {NAME}, and also snooping into the code generated for the application form_PEOPLE_apl.php

    Before updating the database, SC generates this code:

    $this->name = substr($this->Db->qstr($this->name), 1, -1);

    qstr is the AdoDB function to escape the apostrohe; now {NAME} has two apostrophes ( O''Neil )

    After updting the database, SC generates this code:

    if (isset($NM_val_form) && isset($NM_val_form['name'])) { $this->name = $NM_val_form['name']; }
    elseif (isset($this->name)) { $this->nm_limpa_alfa($this->name); }

    which basically sets back {NAME} to his original value. Now {NAME} has his original value ( O'Neil )


    And this is exactly where the BUG is !

    If {NAME} is of SQLTYPE CHAR, then the code to set back the original value is correctly generated, but if it is of type SQLTYPE STRING, then the code is NOT generated and the apostrophe is left duplicated.

    The temporary fix I have found is to modify the FetchField function in the AdoDb code; in the function adodb-db2.inc.php, I forced the return type to be CHAR instead of STRING.

    // returns the field object
    function FetchField($offset = -1)
    {
    $o= new ADOFieldObject();
    $o->name = @db2_field_name($this->_queryID,$offset);
    $o->type = @db2_field_type($this->_queryID,$offset);
    // temporary fix, SQL Char type should be reported as CHAR and not as STRING otherwise SC does not generate proper code and there are issues with the apostrophe
    if ($o->type == "string") $o->type = "char";
    $o->max_length = db2_field_width($this->_queryID,$offset);
    if (ADODB_ASSOC_CASE == 0) $o->name = strtolower($o->name);
    else if (ADODB_ASSOC_CASE == 1) $o->name = strtoupper($o->name);
    return $o;
    }

    In this way SC, after a resync of the table, assumes {NAME} to be a SQLTYPE CHAR and not a SQLTYPE STRING, and correctly generates the code to refresh the orignal value for {NAME}.

    I am not sure if this is a bug of AdoDb , which is considered as a third party library by SC, or it's a bug of SC.

    Indeed the return value of FetchField is not consistent between different databases: MySql and SQLite return CHAR, but DB2 returns STRING, despite the database type is always CHAR and there is no type STRING in DB2.
    Last edited by maxi; 02-16-2015, 02:18 PM.
    Massimiliano Campagnoli

  • #2
    Moved to bugs...
    Albert Drent
    aducom software netherlands
    scriptcase partner, reseller, support and (turn-key) development
    www.scriptcase.eu / www.scriptcase.nl

    Comment


    • #3
      NetMake fixed this bug with last release
      8.00.0033
      Massimiliano Campagnoli

      Comment


      • #4
        Originally posted by maxi View Post
        NetMake fixed this bug with last release
        8.00.0033
        Probably its related to last fix - but after last update mine scriptcase dont like to open forms corectly after copied them to another project
        Parse error: syntax error, unexpected '""' (T_CONSTANT_ENCAPSED_STRING)
        before coping them in old project all is working ok

        Should i report it to support team ? anyone noticed that problem after last update ?
        Problem appear on mysql db non transactional and pdo connection (tested with fail)

        Comment


        • #5
          Originally posted by info@eat.pl View Post
          Probably its related to last fix - but after last update mine scriptcase dont like to open forms corectly after copied them to another project
          Parse error: syntax error, unexpected '""' (T_CONSTANT_ENCAPSED_STRING)
          before coping them in old project all is working ok

          Should i report it to support team ? anyone noticed that problem after last update ?
          Problem appear on mysql db non transactional and pdo connection (tested with fail)
          Could you please create a new thread detailing and demonstrating your problem with some images?

          It is better for understanding and organization of the forum.

          Thank you!
          Best regards,
          Thomas Soares.
          ScriptCase International.

          Email: t.soares@scriptcase.net
          Visit our Blog: http://www.scriptcase.net/blog/
          Visit out fan page: http://www.facebook.com/Scriptcase

          Comment

          Working...
          X