Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    $session availability

    1) v8.3p_2013-03-21/PowerEdition Deployment 2013-03-21

    2) Firefox 20.0 and Chrome on Ubuntu Linux 12.10
    Tomcat 7 server

    3) Please find the error log attached.

    4) Response in the RPC tab :
    [
    {
    data:"ERROR: syntax error at or near \"$\"\n Position: 312",
    invalidateCache:false,
    isDSResponse:true,
    queueStatus:-1,
    status:-1
    }
    ]

    5) Please find my datasource definition attached. Have a look at the whereclause ( I've also tried to do it with the commented out criteria clause but that generates an sql with where ('0'='1') which I cant figure out why)

    The problem is :
    When the user logs in and the fetch on this datasource is executed for the first time, the $session.partybranchid is not interpreted. Its put into the generated query as is in text.
    Here is the query generated the first time :
    SELECT vmapdetails.addressline1, vmapdetails.addressline2, vmapdetails.addressline3, vmapdetails.addressline4, vmapdetails.addressline5, vmapdetails.geocode, vmapdetails.partybranchid, vmapdetails.partybranchname, vmapdetails.phone, vmapdetails.zipcode FROM public.vmapdetails WHERE vmapdetails.partybranchid = $session.partybranchid


    But if I then refresh the browser window, the second and subsequent fetch operations will have the value of $session.partybranchid is interpreted and the substituted in the generated sql.
    Here is the query generated on page refresh:
    SELECT vmapdetails.addressline1, vmapdetails.addressline2, vmapdetails.addressline3, vmapdetails.addressline4, vmapdetails.addressline5, vmapdetails.geocode, vmapdetails.partybranchid, vmapdetails.partybranchname, vmapdetails.phone, vmapdetails.zipcode FROM public.vmapdetails WHERE vmapdetails.partybranchid = '460165190286059'

    hence the operation succeeds the second time but always fails the first time its run.

    Please guide how to resolve this?
    Attached Files

    #2
    This simply means that the HttpSession had not been established yet. This is something you control via Servlets APIs, not SmartGWT. If the session has been established at the servlets level, $session will be available for SQL templates.

    Comment


      #3
      The HttpSession is established on the login.jsp page itself.

      I've verified it by accessing it on the index.jsp page.

      So wondering why the $session.partybranchid is not interpreted. Please help in troubleshooting this.

      Comment


        #4
        What's important is whether the session cookie is sent to the IDACall URL that leads to this log (assuming you are using cookie-based sessions). If its not, there's your problem and that's what to troubleshoot.

        Comment

        Working...
        X