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



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

Different behaviour - Web vs local

  • Filter
  • Time
  • Show
Clear All
new posts

    Different behaviour - Web vs local


    (I've tried a number of different search strings on this forum, no idea what the words are to search for what I believe is some sort of bug), so I'll explain what the problem is, and hopefully this was solved/talked about somewhere.

    I've got a fully functional A5W website, and things seem to be working perfectly fine when running from the LOCAL platinum server. I am using a grid with detail view, and the detail has a variety of "numeric" fields that can be updated.
    I can update the fields easily, along with text boxes etc... everything works fine.

    However, when I publish the files to the remote server, and run the same files, and the same data, (I copied them back and forth to make sure), after I click SUBMIT, (and the record gets posted back, even WITHOUT CHANGING ANY of the data on the detail view), and when the grid loads again, ALL numeric fields get TRUNCATED... i.e. $24,000 gets converted to $24, $1,300 gets chopped to $1

    I've performed a complete publish with ALL files to the remote server, and still the localhost behaves properly, and the remote application server truncates the data.

    Seems it only happens with any values over 1,000. (999 doesn't get truncated.)

    If it was something I've done, then wouldn't it behave the same on each server?

    Obviously this is driving me nuts, as I have no idea why this is happening, or how to debug it! Could this be a bug? OR is there something I could have done?

    Last edited by billkay; 03-15-2009, 09:47 PM.

    Re: Different behaviour - Web vs local

    Determine what the table values are both before and after you submit your grid. Do they start out 24000 and end up 24 after submit, or some thing else? You put quotes around the word "numeric". It is a numeric field type or something else? Is there a calculation on the field in Field Rules? What is your grid property for Size and MaxLengh set to? You show $ in your example, so what is the Display Format for the field? Or is the $ actually in the tables stored value? You said you copy data back and forth, do you PUBLISH the database? And if you do manually copy files, do you include ALL files related to the table, or just the DBF file?
    Steve Wood
    See my profile on IADN


      Re: Different behaviour - Web vs local

      Thanks Steve,

      The fields effected are NUMERIC, with 8 width, and 0 decimal.
      If I manually input 24000 into the detail view and click SUBMIT, all updates as expected, and $24,000 is displayed in the grid view.
      IF I click the detail view link again, to display the detail view, still displays correctly, however If I press SUBMIT (even without altering anything on the detail view), the (now $24,000) gets changed to $24 when the grid comes up.
      Yes, I am using the publish features (I manually copied all dbf, fpt, ddm, ddd, ddx files from live server back to local, made adjustments (like made all numeric fields the same lengths (now 8), then copied them back to the remote).

      Yes, the data in the table appears as it is displayed in the form. There are no transformations in the database tables. It seems that the conversion happens upon SUBMIT.

      Seems for some reason, when the value is displayed in an editable field (text box) as $24,000, when submit is pressed, Alpha barfs at the "," and drops it. It then stores 24 in the database.

      When the data is called it displays $24

      I'm thinking the problem is the alltrim(str(<value>,250,0,"$(")) that I have on each and every field "Display format" (even the textboxes in detail view), but this should only effect what is being displayed, and not what is stored? no?

      When the data gets posted back to the database, I would expect the $ and the , to be stripped, leaving 24000 to be posted, but it doesn't, it instead truncates everything after the ,. Any number 999 and under is not effected (I guess because there is no comma!?).

      Funny... it was working perfectly in a previous version, and only now has it broken when I did the latest update.

      Thanks Steve for any other ideas!


        Re: Different behaviour - Web vs local

        Not sure, but try:


        BTW: "250"? Seems like overkill, no?
        AlphaBase Solutions, LLC

        [email protected]


          Re: Different behaviour - Web vs local

          Seems to work even if I put 2500 in the length field, but yes I would agree that parameter should be no bigger than what the table field will actually hold.

          Are you sure the fields are Numeric, and not perhaps NumericExponent type? I have no problem in my test, using your display format in grid or detail. But I do get that problem if I change to numericexponent type.

          How about attaching your grid here for us to test.
          Steve Wood
          See my profile on IADN


            Re: Different behaviour - Web vs local

            What happens if you put a value without comas? ej. 24000
            does this gets truncated too?


              Re: Different behaviour - Web vs local

              OK, ran a few more tests...

              If I go without commas, it gets stored properly only on the FIRST SUBMIT, then when it gets redisplayed, I get $24,0000 (as expected), but then when I click to editable grid and click submit it gets truncated again before posting to datatable.

              (The 250,0 was just the default that the "wizard" inserted... I've since changed it to 8,0 and 10,0 (and even tried 10,2) to no avail. I don't wan't/need cents)

              Table particulars:
              NUMERIC data type.
              Width = 10 (Was 6, I've increased it just in case)
              decimal=0 (I don't need cents)

              This does not work...
              Setup in Gridview, and has link to detail view where editable:
              Grid view
              Field Display format = alltrim(str(<value>,10,0,"$("))
              Detail View
              Field Display format = alltrim(str(<value>,10,0,"$(")) (this is an editable text box)

              Once SUBMIT is pressed, (even if nothing changed) (BTW, maybe the system THINKS something is changed.?.. as the data in the table says 24000, but $24,000 is DISPLAYED in the editable text box. Once submit is pressed... I check the table and it contains 24

              There are no transforms in the table

              If I remove all Field Display Formatting, BOTH in the grid and the detail view editable text box, then everything works fine, however, of course everything is displayed without formatting.

              Strangely, I would expect that as a minimum it would allow me to at least display the grid values with alltrim(str(<value>,10,0,"$(")). If I click the detail view link, it still pulls in the formatting from the grid view, even though none was specified for the text box in the detail view.

              Maybe the best question to ask now would be, "What is the proper setup to be able to store a currency in a table, where the currency is stored as a whole number, and is displayed in the grid as a $nn,nnn, and also in the editable grid portion as $nn,nnnn, but will allow a user to input nnnnn into the field, and store it properly. Should I even be THINKING I should be able to display the currency in an editable text box (detail view) like $24,000?? I would expect it to be possible, then when posting, Alpha should strip the formatting off it, before posting to the database table. Maybe I'm wrong.

              It is most definitely something to do with the alltrim(str(<value>,10,0,"$(")) display format and where/when to use it. Maybe my ideas of what I'm expecting of Alpha5 is out of line.

              Thank again for any tips... If no ideas, I can post the component, for your review. It's a biggie...


                Re: Different behaviour - Web vs local

                One obscure thought, and I did not test this, in Numerics the "0" is the same as a null. If you alltrim() what is, or was (before the str()) a numeric 0, would that strip it off? This doesn't sound plausable but I will press the Reply button anyway.
                Steve Wood
                See my profile on IADN


                  Re: Different behaviour - Web vs local

                  Ok... another discovery...

                  I've removed ALL formatting, in both grid view and detail view.

                  If in the detail view I put in a $24,000 and click submit, it gets truncated to 24.

                  $24000 (without comma) is accepted properly!!

                  It is most definitely the COMMA!

                  I would have expected an "error" of some type, but instead, it accepted it and just truncated it.

                  Thus, I would presume that when the COMMA is added to the display format in the EDITABLE text box, the editable grid sees this as a CHANGE in the data and attempts to post it back, where the system (somewhere) truncates it at the comma

                  Again, I am positive that this was functioning properly in a previous minor release (2 weeks ago?), only now it is truncating.

                  I'm just blindly using the "Select Pre-Defined Format".

                  Thanks again!
                  Last edited by billkay; 03-16-2009, 10:22 AM.


                    Re: Different behaviour - Web vs local

                    There is a place in the settings where you can tell Alpha what the character is for decimal point. Sounds like yours is set to comma instead of period.

                    Pat Bremkamp
                    MindKicks Consulting


                      Re: Different behaviour - Web vs local

                      Thanks Pat,

                      If you can point out where that is, I'd love to give that a try.



                        Re: Different behaviour - Web vs local


                        Sorry, it was in the field validation instead of settings. If you click on validation for a numeric field and if you set the numeric type to fixed or variable decimal, then you can see the choice. You can't see it for integers.

                        Pat Bremkamp
                        MindKicks Consulting


                          Re: Different behaviour - Web vs local

                          Thanks everyone...

                          I've been PM'd with the solution... thought I'd share...

                          in the field UNformat. This way Alpha doesn't get confused with the commas being passed back.

                          All works proper now, but I'm convinced it all USED to work. hmmmm.... ;)



                            Re: Different behaviour - Web vs local

                            I have seen something similar to this somewhere else.
                            In some parts of the world apparently 1,234.56 can be written as 1.234,56
                            thus this problem could indeed be in Windows, and possibly the LOCALE of your server is different to that of your development machine.
                            Just a thought.


                              Re: Different behaviour - Web vs local

                              Yes Bill that used to work i think , I got the same error a couple of months ago and I decided to tel the user to feed numbers unformated not allowing special characters in the validation rules and displaying the field without format, Im glad you found a work arround

                              By the way this problem only occurs in dialogs and not in grids (in my case)