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

List will not write to SQL

  • Filter
  • Time
  • Show
Clear All
new posts

  • List will not write to SQL

    Hey all

    Over the past year I have been moving an old MS Access front end / back end database onto Alpha and SQL - so I am working with legacy tables that have been uploaded to the SQL Server (Zebra Host) using the MS SQL Migration Tool.

    The original developers used a lot of spaces and even dollar signs in field names - this has caused me a lot of headaches but I have to keep the fields as they are as I have to keep the original MS Access Front End in place while we move the functions over to Alpha.

    One of my tables is called Customer Equipment and I need to be able to add records to it. If I make a UX with a list control and detail section I can scroll through the records and add new records no problem. The file has 35000 + records in it. This list really needs to be a child list to my WORK ORDERS list, linked by a customer number. So I have placed the Equipment List on a second panel, linked it to the Work Orders and it all looks great. I can see the records I want to see but when I go to add a new records I get SQL error saying that it Alpha cannot find the Customer_Number field.

    Why would I see this error when the list is a child on a UX but no when it is the only list on a separate UX? I used the genies to build and bind the controls - so if the genie made the field why can't Alpha find it when it goes to write to the same field? I hope this makes sense.

    I have attached a shot of the error I get.

  • #2
    Re: List will not write to SQL

    You have a lot of variables going on here. I'd have to see the setup to really give you some help.

    Even though you let Alpha do the work, at this point you need to check the data-bindings of that control for yourself. You might even unbind it then rebind it back again.

    However, I don't completely understand what you are doing. Are you keeping the field and table names the same so it is easier to migrate the data?

    I don't recommend this approach to your programming.

    You would be better off changing the field names in the SQL, then developing an export/import routine to move the data on future tests. The data move will be more of a pain, but your application will be better (and easier to program) in the long wrong.


    • #3
      Re: List will not write to SQL

      I have to keep the field names and table names the same so that the MS Access front end that is existing still works. We used Alpha to allow mobile access to the data for our field staff and are still using the MS Access - from the 1990's - to do most of the back office tasks.

      If I cleaned up the tables at this point it would cause my front end to not work and shut our operation down...

      My plan was to get the most of the functions working in Alpha as the first version and then go back and optimize the Alpha and data structure as a separate project.


      • #4
        Re: List will not write to SQL

        I see.

        You migrated to MS SQL, but the front end is still Access, now using the SQL db instead of the Access DB.

        Alpha is just using the DB for a few tasks that are expanding as you go along.

        Depending on what some of your field names actually look like, you are likely going to have some issues in MS SQL.

        However, here are some other things to check:

        Make sure your Primary Key is properly set for each table and that Alpha can see it.

        Make sure your lists are based on Primary Key instead of Field. (They default to field.) This can solve ALL sorts of problems.

        Turn on the ability in your UX to see what alpha is trying to save. Sometimes you can see the problem there.


        • #5
          Re: List will not write to SQL

          It's really all just guesswork for this type of issue. You only have a couple of tables involved. Copy the tables, structure only, and then add a couple of test records into each. Build your test UX using these tables and confirm the issue is still present. Then post the test UX and a sql export of the test tables. This would take a fraction of the time spent on posting and guessing and responding and guessing. Then you'd have people actually looking at the problem. And... you've not mentioned the Alpha Build you're using or the MS SQL Version.


          • #6
            Re: List will not write to SQL

            Thanks David and Larry

            I made new files on my SQL server mirroring the ones that were uploaded using the Microsoft Migration Tool. I tested the UX's on the new table definitions and they worked. Then I migrated the data from the original tables into the newly created one and things are working fine now. I am glad to know the problem was with the data and not Alpha.


            • #7
              Re: List will not write to SQL

              One option regarding the problematic field names is to create SQL views for each table. In the SQL view, use the "Alias" field to rename the problematic field names to whatever is more suitable to your needs or naming conventions. Then use the SQL views in your Alpha components. If you do this, I recommend creating a cross reference doc which will make life easier when debugging any data related issues