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

What has v11 done with Session variables?

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

  • What has v11 done with Session variables?

    I have some web pages that have been working for years in A5v7 through A5v10 WAS. But they won't work in v11 and I can't see an easy way to fix it.

    Problem was originally noticed because of a login issue with a variable called Session.DataPath that - surprise, surprise - stores the path to the data folder. I set this variable in the index page. In v11, when I go to the Login page, that variable is still valid. However, when the user clicks the Submit button the Login page is re-read (to decide whether or not the user successfully logged in before redirecting to the appropriate page) and at that point the Session.DataPath variable is no longer valid - thus triggering a response.redirect() to the restart page.

    Testing reveals that all session variables set in the index page disappear when I click the Submit button but all session variables created on the current page remain valid. WTF??

    Remember - this worked perfectly for years in the earlier versions.

    I've attached a slightly modified version of the web page. (Modified to protect the owner of the site only.)
    WARNING: This is not your typical A5 web page. There are no web components and no "publishing" info. This is a hard coded web page that can just be copied to the website and it will work - assuming you have the tables and the variables from the Index page, of course.

    I'm hoping I can find a simple solution. Otherwise I will have to completely rewrite every web page on this site using some other method than Session variables because most pages call themselves for validation before moving to the next page.

    By the way, anyone who uses the A5_default_path variable in the WAS will have to modify their pages. In all earlier versions this returned the path to the current page and included a backslash on the end. In v11 the backslash was removed. (Again, WTF? I assume there was some kind of reason for this but I really appreciate the idea that I will now have to check this on every website I've created when it gets updated to v11. Especially if we weren't told about it.)

    LATER:
    Sorry about the attachment. I realized I hadn't uploaded it right after pressing the "Post" button. But then I got a "Website being updated" message and couldn't edit the message. Then my wife called me for dinner and that trumps everything else.

    I haven't looked at the linked info yet but I'll post the attachment anyway in case anyone wants to look at it. And I'll let you know what I figure out once I've studied the additional info.
    Last edited by CALocklin; 01-04-2013, 10:55 PM.

  • #2
    Re: What has v11 done with Session variables?

    There's no page attached. Session variables are no longer variables but rather objects. So don't dim you session as P. Look in the v11 release notes, i think. I saved it; here's a copy:

    Xbasic - DIMMing Variables - A change has been made in how Xbasic operates when DIMMing a dot variable. If the user has not explicitly specified the scope in the DIM statement, Alpha Five will now try to see if the dot variable parent container already exists in all scopes (GLOBAL, SHARED, etc. ) and if so, it will DIM the variable in that scope rather than creating a new locally scoped variable.

    It is possible that this change will break an existing application in some way. We think that chance of this breaking existing applications is extremely small, but if so, the change to your Xbasic to fix the problem will likely be very simple, as explained below.

    The following example will illustrate the point.

    dim global myGvarContainer.myvar1 as c = "alpha"
    dim myGvarContainer.myvar2 as c = "beta"

    In the above example, the user was explicit about the scope in the first statement, but not the second statement. As a result, with the previous version of Alpha Five, the following variables were created:

    myGvarContainer - a pointer variable in the Global name space
    myGvarContainer.myvar1 - a character variable in the Global name space
    myGvarContainer - a pointer variable in the Local name space (created by the second command)
    myGvarContainer.myvar2 - a character variable in the Local name space

    Now, as a result of the change, the following variables are created by the above two commands:
    myGvarContainer - a pointer variable in the Global name space
    myGvarContainer.myvar1 - a character variable in the Global name space
    myGvarContainer.myvar2 - a character variable in the Global name space

    In the above example, had the second DIM statement been written as:
    dim global myGvarContainer.myvar2 as c = "beta"

    the the old behavior of Alpha Five and the new behavior would have been identical.

    To reiterate the point here, if you look at the second DIM statement above, you see that there is no explicit scope. But since Alpha Five can find the variable container ('myGvarContainer') in the Global name space, the new variable ('myvar2') is created as a child of the existing variable in the Global namespace, rather than creating a new variable in the Local name space.

    In the above example, if you want to preserve the old behavior, you can easily do so by adding this extra DIM statement (shown in red):

    dim global myGvarContainer.myvar1 as c = "alpha"
    dim myGvarContainer as p
    dim myGvarContainer.myvar2 as c = "beta"

    Now there will be two 'myGvarContainer' dot variables - one in the Global name space and one in the Local name space, and the DIM statement for 'myvar2' will create a Local variable (just as it did before this change was introduced).

    Why was this change made? The reason this change was made is that users were breaking their Web applications by writing code like this

    dim session.var1 as c = default ""

    The reason for doing this was to ensure that a session variable existed before its value was tested. For example:

    dim session.var1 as c = default ""
    if session.var1 = "value1" then
    'do something
    end if

    This would not work as the user was probably expecting because the DIM statement was actually creating a LOCAL variable called 'session' and then DIMming 'var1' as a child of the LOCAL 'session' variable.
    The user was likely expecting the above DIM statement to DIM 'var1' in the Global 'session' object.
    Now, as a result of the change made in this build, the above statement will DIM var1 in the Global 'session' object.
    Note however, that this code pattern would still be wrong and would lead to errors:

    dim session as P
    dim session.var1 as c = default ""
    if session.var1 = "value1" then
    'do something
    end if

    This would create a LOCAL variable called 'session' that would mask the global 'session' object and 'var1' would have been created as child of the local 'session' variable.

    Bottom Line: Do not put 'Dim session as p' in your Xbasic code in Web Applications unless (in the incredibly unlikely event) that you actually want to create a local variable of type P in the LOCAL name space.
    Peter
    AlphaBase Solutions, LLC

    [email protected]
    https://www.alphabasesolutions.com


    Comment


    • #3
      Re: What has v11 done with Session variables?

      Cal - things are indeed changing as we move toward V12 and IIS.

      You should know about this:

      http://wiki.alphasoftware.com/Server...+in+Version+11

      and that session variables now must always be character-type.

      You'll find other threads as well about writing to and using the session folder.
      -Steve
      sigpic

      Comment


      • #4
        Re: What has v11 done with Session variables?

        Originally posted by Peter.Greulich View Post
        There's no page attached. Session variables are no longer variables but rather objects. So don't dim you session as P. Look in the v11 release notes, i think. I saved it; here's a copy:
        I have to differ with Alpha's explanation on this.

        Why was this change made? The reason this change was made is that users were breaking their Web applications by writing code like this

        dim session.var1 as c = default ""


        (Disclaimer: I have no idea why they added the default "" in there. I know what it does; I'm just not sure why it was added. Maybe that's the catch compared to my simple DIM statement.)

        First, they told us that any variable that started with "Session." would be available throughout the session.
        Second, that's exactly the way it worked from the original beta version through v10 - whether DIMed or not.

        The only time it doesn't work is in v11. In fact, even in v11 it works when first going to another page! It only disappears after calling the current page again.

        I understand what they are saying and, logically speaking, it makes complete sense. But that's not the way it worked - not until v11. I've created websites that are working in v7 and v9 and worked on them in v8 and v10 on my desktop and they always worked even if a variable such as mine was created as:
        DIM Session.DataPath as C

        Now, on to the stuff Steve referenced.
        Last edited by CALocklin; 01-04-2013, 11:12 PM.

        Comment


        • #5
          Re: What has v11 done with Session variables?

          All clear as mud. At least I know I have never used "Dim session as p" in any app, so I am clear there. For the other rules, I think I have to resort to actually testing to see how it all works.
          Steve Wood
          Join the ALPHA DEVELOPERS NETWORK
          There is no Cloud. It's just someone else's computer.
          Web - Mobile - Hosting - Products - Frameworks - Developer Resources
          AlphaToGo | IADN (100% Alpha Anywhere Websites)

          Comment


          • #6
            Re: What has v11 done with Session variables?

            OK, this is getting even more confusing. Or maybe someone at Alpha is confused.

            The stuff Peter posted says not to do this:
            DIM Session.name as C ...

            Then the stuff Steve referenced shows this:
            session_vars.png

            So apparently we're not supposed to do what we're told to do? (Good luck trying to train your kids using this method.)

            Comment


            • #7
              Re: What has v11 done with Session variables?

              OK, now that I've read the stuff Steve linked to, I'm still no further ahead. I see nothing there that will fix/cause my problem.

              Also, after another look at the stuff Peter posted, I'm even more confused.

              First, is the stuff Peter posted only referencing XBasic on the desktop and NOT the web app server? (It starts out with Xbasic - DIMMing Variables) If so, the description would make more sense BUT, if that's the case, why in the world did they choose to use "Session" as the pointer name? Also, what do GLOBAL variables have to do with the WAS? Isn't that replaced with a SESSION variable?

              Second, that info should actually "fix" my problem. It says: (emphasis added)

              dim session.var1 as c = default ""
              if session.var1 = "value1" then
              'do something
              end if

              This would not work as the user was probably expecting because the DIM statement was actually creating a LOCAL variable called 'session' and then DIMming 'var1' as a child of the LOCAL 'session' variable.
              The user was likely expecting the above DIM statement to DIM 'var1' in the Global 'session' object.
              Now, as a result of the change made in this build, the above statement will DIM var1 in the Global 'session' object.


              So, since I've never explicitly DIMed the "session" pointer, shouldn't this "fix" make it work better? (Or, as far as I'm concerned, like it always did in the past with the web app server.)

              On to more - probably hours - of testing. (I've already spent over 2 hours on this - thanks for the changes Alpha.)

              Comment


              • #8
                Re: What has v11 done with Session variables?

                Cal, you're making this too hard.

                The snippet you show from the wiki is about setting session variables from request variables. Ignore that for now because that's not what you're doing or need right now.

                Instead, just simply DIM each variable in a simple form:

                DIM MyVar1 as c
                DIM MyVar2 as c
                DIM MyVar3 as c

                If you'd like, you can assign a value to the variable at the time you DIM it:

                DIM MyVar4 as c = "123"
                -Steve
                sigpic

                Comment


                • #9
                  Re: What has v11 done with Session variables?

                  Originally posted by CALocklin View Post
                  So apparently we're not supposed to do what we're told to do? (Good luck trying to train your kids using this method.)
                  I have been telling my kid for years not to do the things I did regardless of my parents telling me not to do it.

                  I think backwards compatibility is -enterprise wise- a great good and should not be given away that simple, but ONLY as a last resort and ONLY if you have an easy fix. The last thing is rather difficult since because the code allows several approaches programmers will produce strongly varying code solving similar problems.

                  The fact any software manufacturer can do this without short fusing its relationship with the customer sort of tells you something about the general Alpha customer and his products I guess.

                  Breaking backwards compatibility that easy has been the reason why my company could not update from version 5 upward anymore because of the misery that produced. What was allowed code-wise up to version 5 would not work anymore in version 6. However, since this particular application was sort of a living organism that changed on a daily basis, we simply could not change it to meet v6 requirements (even with a 6 person development team on it) since the part we would work on would be changed feature-wise by others the same day and so on. For large applications breaking backwards compatibility can be a showstopper for upgrading and keeping up with the Alpha product life cycle. I am quite sure in our case it did cost Alpha Software a significant amount of sales revenue since when your application can't run on newer versions it sort of defeats the reason to purchase the upgrade to begin with.

                  If you break backwards compatibility, you should be damn sure you got the consequences for your customers covered completely or offer your utmost to help them cope with it. That's my opinion on it.

                  Comment


                  • #10
                    Re: What has v11 done with Session variables?

                    I agree that it is a lot of work, and a bit confusing. I've done enough conversions now that I think I will spend 2013 just doing conversions of existing application, provided willing clients surface.

                    I find it challenging and at the same time conversions have a "routine" quality to them where certain steps must be taken in order. An application written in V8, V9, V10 is probably due for a house-cleaning, and V11 definitely is a paradigm shift in how data is presented to the user (TabbedUI). Conversion also means from DBF to SQL because I find many developers want to go to SQL but are not sure how.
                    Steve Wood
                    Join the ALPHA DEVELOPERS NETWORK
                    There is no Cloud. It's just someone else's computer.
                    Web - Mobile - Hosting - Products - Frameworks - Developer Resources
                    AlphaToGo | IADN (100% Alpha Anywhere Websites)

                    Comment


                    • #11
                      Re: What has v11 done with Session variables?

                      I always find it a bit amusing how now all must be SQL and DBF is assumed to be of "inferior quality" whilst in the past ten years or so we were all lead to believe it was almost as good as perfect. Is this what is called "marketing" ? Promote what you can actually sell, and not what your neighbor sells but you yourself can not?

                      SQL has a lot speaking FOR it, doubtlessly, and it is the defacto market standard for midrange use, but.... it has also things speaking against it, not in the least being the problems you encounter if you are selling off-the-shelve and pre-packaged software.

                      That said, I am not saying DBF is equal to or better then SQL, because I know from experience it is not. I am just amazed how those things work. Once we did not have it in Alpha, DBF was great and talking about SQL was not done. Now we do have SQL all DBF is inferior and must be exchanged for SQL. Amazing.

                      Given the principle that most developers will build an app to the best of his knowledge and experience, the necessary "house-cleaning" as you say Steve is most of the time not triggered by bad programming in the older version, but because of added features or changed interpretation of code, such things. The amount of work that takes can be considerably decreased if the manufacturer of the software accommodates such "house cleaning procedures" in the upgrade. Code interpretation seems to become increasingly tighter as the versions become higher. Pieces of code that you actually COULD run in v5, you could not run anymore in v6. Doubtlessly in most cases the developer would not have programmed exactly to syntax standard which then in the end, when the interpreter works tighter, delivers a problem. I have seen that in many, many cases. The problem increases in quantity once you promote your product to be something you do not have to code in at all since you obviously will then get customers who can't write good code to begin with.

                      I agree with you that it is challenging. Although in most cases I would have hoped the challenge would be non-existence to begin with. It is always better for you to spend your time in delivering a product that gives your customer extra functionality then him needing to pay you to "repair" functionality he already had to begin with.

                      Comment


                      • #12
                        Re: What has v11 done with Session variables?

                        I've had to bite the bullet and start changing to the new Alpha approach in old apps. I have customers who bought V11 subscriptions in order to upgrade and were very upset when told it was a major effort to upgrade.

                        The only customers who are happy are the new ones who bought V11 as their first Alpha product where the V11 approach could be used from the beginning.

                        So, for example, a small piece of an old page SetSessionVars.a5w that used to read
                        dim session.logo as p
                        session.logo.name = "MyLogo"
                        session.logo.high = 130
                        session.logo.wide = 220
                        session.logo.alt = "Company logo"

                        now reads
                        Session.LOGONAME = "MyLogo.jpg"
                        Session.LOGOHIGH = "130px"
                        Session.LOGOWIDE = "220px"
                        Session.LOGOALT = "Company logo"

                        Not better, not worse, just different.
                        Fortunately, I had this all in one place, then could use the new search to find everywhere the old ones were used. Took about 12 hours to convert the first app. Also, it was very fortunate that this was an SaaS app so I only had one generation of this software to maintain. I had tried selling copies of the app for a while and luckily, I wasn't successful. Can you imagine if I'd been trying to maintain multiple old versions? A nightmare!

                        Also, I think I'm one of the few who used server variables to good advantage. That was also deprecated...more hours!

                        And, yes, it can take weeks to convert an app from V10 dbf to V11 SQL.

                        I have yet to see the advantages of all this .NET integration that makes this all worth while, but then I've learned Xbasic, many of the Alpha functions, Xdialog, html, css, MySQL stored procedures and I'm only part way through JavaScript, so it'll be a while before I have time to learn that, too. I've only seen two posts on this board about .NET, both from people who already knew .NET and were trying to learn Alpha, so I don't think very many people are using it.
                        Pat Bremkamp
                        MindKicks Consulting

                        Comment


                        • #13
                          Re: What has v11 done with Session variables?

                          Yes of course you promote what you have. That is not disingenuous, how can you promote, provide instruction for, etc. for something you donít have?

                          Alpha made a commitment to add SQL and has done a pretty good job of it, except for documentation.

                          Did somebody say you must convert to SQL? No one said that. And I don't recall Alpha "promoting" SQL like is was mandatory. But I will say from my perspective SQL is better than DBF in every way -- including portability, power, speed, simplified routines, simplified syntax and unlimited online reference material. But it is still a jump to go from DBF to SQL; it took me several years. The reason you are hearing about SQL now is not so much because of Alpha but because a lot of DBF-die hard Developers now work exclusively (or as much as possible) with SQL. It is impossible for Alpha to write some automatic routine that would migrate an application from DBF to SQL or even from V10 to V11.
                          Steve Wood
                          Join the ALPHA DEVELOPERS NETWORK
                          There is no Cloud. It's just someone else's computer.
                          Web - Mobile - Hosting - Products - Frameworks - Developer Resources
                          AlphaToGo | IADN (100% Alpha Anywhere Websites)

                          Comment


                          • #14
                            Re: What has v11 done with Session variables?

                            Originally posted by mronck View Post
                            If you break backwards compatibility, you should be damn sure you got the consequences for your customers covered completely or offer your utmost to help them cope with it. That's my opinion on it.
                            Now when Alpha is heavily integrating to .Net I hope they do finally something radical and also "clean" their xbasic to a valid logical language which would be easy to learn and easy to use.

                            The ongoing model in xbasic to keep everything old and and add some new is not a right direction to go anymore.
                            Xbasic functions and their naming system is a big mess today.

                            Now It is time to really break the compatibility and give us something really good and unique features in xbasic because .net integration now gives a one time opportunity to do that.

                            Comment


                            • #15
                              Re: What has v11 done with Session variables?

                              Originally posted by Steve Wood View Post
                              Yes of course you promote what you have. That is not disingenuous, how can you promote, provide instruction for, etc. for something you don’t have?
                              I like to promote things I believe in and stand behind. Not necessarily "what I have". There is a difference there Steve. I think it will be just THAT difference that will sign for the major changes in the world in the next Age. We need to go from "commerce" to "integrity" in increasingly more aspects of what we do.

                              That said, I think that the whole DBF line is nearing the end of its life cycle. SQL is available to us, but only that fact will not determine either whether it is the tool for the future. The future is never an open book. Neither is it for Alpha's management who is now staking their hopes on mobile programming. Who knows, it may be it. Or it may be not. I am quite happy I am not the one who needs to decide now for what to produce tomorrow. I try to create what my customer expects, and hopefully plus 1. The Expectation Plus One. That's what I aim for.

                              Comment

                              Working...
                              X