Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Before Validate New Records Error

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

    Before Validate New Records Error

    I'm getting the following error and can't figure out why: Error executing BeforeValidateNewRecords event handler: command: DataSubmitted.userid=session.__protected__userid Property not found
    session.__protected__userid subelement not found.
    I've been using Steve Wood's code for years in dozens of applications but suddenly it won't work on one where it's been used before.
    I get the same result in any of several pages and also when running on my local host. I'm suspecting it must have something to do with the login/password, since that's the only common factor.
    Any help would be most appreciated.
    --Al Kingsbury

    #2
    Re: Before Validate New Records Error

    As of V11 all SESSIONS are protected by default so it looks like session.userid. Secondly there is the offical advice from Alphasoftware to declare all sessions vars of type C to make it to run under feature IIS.
    Wird is that i am running the last pre-release of V11 and i declare as session.__protected_myvar as without errors, If your running V3 contact Steve directly as he is the developer of the A2go framework.

    Comment


      #3
      Re: Before Validate New Records Error

      Eric is right that all session variables should now be character-type.

      Eric is also right that all session variables are now automatically protected. So, you don't need to have the __protected__ part of the string, but it does no good or harm - just causes more typing.

      But Eric's assertion is the system is now looking for session.userID, even though you named it session.__protected__UserID is not correct. If you call for session.__protected__userID, it will look for and use session.__protected__UserID.

      If you already have an app that has variables with __protected__ in them, it's OK to leave those names alone. But, if the variable type is not character, then you'll have to deal with a conversion to character type. The convert_type() function is very useful here.
      -Steve
      sigpic

      Comment


        #4
        Re: Before Validate New Records Error

        It comes down to the same it is more than a year ago announced obvious session.__ replace the old with the new method as stated. Alpha may at any time decide that with immediate effect no longer support your webapps that no longer works. Otherwise, what is the reason as to communicate the message forum and the wiki V11 changes. I see it happen again, most wait until the last moment and then suddenly everyone starts to scream with no longer works and Alpha Sucks etc. Maybe I misread that is possible but I choose security and have everything in time replaced and tested so I'm ready for IIS and my clients. Procrastination is adjustable and creates unnecessary panic you could have prevented, but then who am I?

        Comment


          #5
          Re: Before Validate New Records Error

          Eric - the reason I decided to post what I did is that there seems to be considerable confusion and mis-information about session variables as we head to V12. A lot of people are even asking me about the "news" that you can't have session variables in V12 -- it's that confused. Of course, you can.

          You seem to be suggesting in your message that there's something in the documentation or otherwise from Alpha that says my posting is incorrect. I'm quite certain it is not. In fact, I've just moved a client from the old "session.__protected__myvariable" arrangement into V11 compatibility. I did not have to change the session variable name, only it's type when it wasn't already character.

          Do you have something you can point to that disproves my point here? I posted to help clarify the situation; there's always the chance that I'm wrong, but please provide a clear explanation and maybe source as to what I'm wrong about, or why, else people may read your post and decide that maybe it's still not clear.

          Thanks.
          -Steve
          sigpic

          Comment


            #6
            Re: Before Validate New Records Error

            This is the basic document from the Wiki:
            Application Server Functionality Changes for V11


            Browser Tracking
            The Application Server no longer performs automatic browser tracking. Previously, a BrowserId cookie containing a unique identifier with a long lifetime was sent as part of every response, and that identifier was made available as Session.BrowserId. The cookie is no longer set and the Session.BrowserId property is no longer created.


            Caching of A5I files
            The server now actively monitors all a5_application.a5i files for changes and automatically refreshes the cache as needed. This negates the need to use Server.ClearA5ICache() or restart the server when A5I files are updated.


            Caching of Gzipped Output
            The server now actively monitors all gzipped output for changes to the underlying source file and automatically refreshes the cache as needed. This negates the need to use Server.ClearGzipCache() or restart the server when static files are updated.


            MIME Types
            The Application Server now resolves MIME types using settings stored in an XML file. This allows the server administrator to add MIME types to extend the server or to override the default types.

            The location of the MIME types file may be specified using the Advanced tab of the Application Server Settings. It defaults to a file named MIMETypes.xml in the same folder as the server's configuration file.

            If the specified file does not exist, the server will create a new XML MIME types file using internally stored defaults when it is first started. The file will then be used for subsequent starts of the server.


            Session Files
            Files are now stored in the session using Session.SaveDataAsFile() and retrieved using Session.FormatFileDataURL(). See Storing Files In Sessions V11 for complete details.


            Session Variables
            Session variables can only be strings (type "C"). While this limitation has always been implied, it has not always been strictly enforced, so legacy code may store other data types as session variables. Going forward, this will not be possible, as it will break session persistence.

            Session Variables cannot be created directly from a request query string or POST body. This negates the need to use "protected" session variables, as all session variables are now effectively "protected". In order to create a session variable, you must execute A5W code to read the request variable and create or set the session variable. A request for a URL such as http://localhost/index.a5w?session.name=John will not create a session variable session.name as it previously would have. Instead, it will create a request variable which may be accessed as Request.Variables.session.name during the lifetime of that request only.

            There is also a note in the release notes before nov 7 2012 but i can't find that anymore it all has todo with the upcoming IIS api.
            Best option is to ask Alpha team for an update about policy how to use session vars in V12 and to exlplain <renew/update> and how developers should prepare then we don't have to debate how is right or wrong as we are users of the product and not the vendor. I think you agree

            Comment


              #7
              Re: Before Validate New Records Error

              I think that my post #3 covers it.

              And you can have this:

              session.__protected__myvariable
              or this
              session.myvariable

              in fact, you can even have both -- because they have different names, they are different variables.

              They are both "protected".

              They must both be character type.
              -Steve
              sigpic

              Comment

              Working...
              X