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

input please! multi lots, protected

  • Filter
  • Time
  • Show
Clear All
new posts

  • input please! multi lots, protected

    I am building a complete project in alpha. there are to be multiple lots (cars) and according to the user about 5 levels in each lot.

    I have the idea to open in an adb in main folder and then let the user choose which (lot) folder to go to next and start another mdb from there. All the folders will be identical except for data. once into the folder the users level will let him open a mdb that lets him go only where allowed.

    In other words lot 3 may be folder - folder3 and adb may be 3.abd because he has no rights to see costs.

    Make sense?

    Input of feasability please.

    There are many other ways of doing this, but I've seen some of them and don't wanna repeat them.

    Dave Mason
    [email protected]
    Skype is dave.mason46

  • #2
    RE: input please! multi lots, protected


    I think multiple folders could turn out to be a devil's bargain. You could manage them but who needs extra problems.

    Would there be a drawback to a single adb in a single folder with a separate table for each level? I personally would go further to a single table with a field for level. Let the application open to a main menu with buttons for each level. Each button opens a different form (of a different color)which has a built-in filter on the level field. Users would always know which levelthey were on.

    I am sure you have reasons for avoiding this approach but lots of folders could lead to lots of pains in the neck.

    Bill Hanigsberg


    • #3
      RE: input please! multi lots, protected


      Thanks for the input.

      This app will use a login with username and password for entry and the different permissions.

      I believe that the forms would be the same in the levels, however I intend to run (say) 5 different adb files in each folder that wont let the user see the forms/reports/etc they are not supposed to used. Each adb would be its own app. Explain: salespeople do not need to see cost of inventory, but need to run a credit app and input a deal maybe.

      I need to think about what you said more. The forms could do the same thing.

      The folders will be completely identical (except for data), facilitating easier updates.

      Dave Mason
      [email protected]
      Skype is dave.mason46


      • #4
        RE: input please! multi lots, protected


        I have a similar problem but with different data. I have all my academic departments scheduling courses in a single complex of tables in a single adb, and all in a single folder. But each department only sees its own data. The filter process is automated in the logon script which dynamically creates filters on the forms. Nobody knows the control panel exists.

        It isn't cars, and it isn't money, but it still is segregation of data based on need to know, a problem which appears to be thoroughly generic to the kind of stuff we're all doing.

        I'll be interested in the approach you ultimately take and, especially, the reasoning behind your choice.

        Bill Hanigsberg


        • #5
          RE: input please! multi lots, protected

          Hi Dave,

          I concur with Bill. Don't go down any other road without a compelling reason. Sure you have to build in security (Version 5 will do it for you), but you'd have to have the same security to keep people out of the different levels anyway. Use different forms, or use conditional objects on forms (or any number or other constructs) to hide/show data for different security levels.

          Just my two cents,



          • #6
            RE: input please! multi lots, protected


            I'm going to chime in with Bill on this one. Once your database starts to spread beyond one folder Alpha Five will begin automatically embedding physical path information in its dictionaries. This is physical path, not relative path. The consequence is that the app immediately becomes much, much less portable. Unless you want to build (and maintain) matching drive and folder structures on each customer's machine, you *really* want to keep all the pieces of a single database in one folder.

            Having said that let me add that putting more than one database in a single folder is sometimes a good choice, so long as each component of all the databases reside there, too. However, I've found that this makes system wide maintenance (reindexing, packing) and some types of reports more difficult.

            If I were you I'd look for ways to do it inside a single folder, using a single ADB.

            -- tom


            • #7
              RE: input please! multi lots, protected

              Here's another 2-cents worth:

              I agree with Bill and Tom, keeping it all in one ADB. I'd further agree with Bill in keeping the app in one DBF, and using filters. I've also done it this way, and it's very smooth. I've also done it with separate ADB's, and I really don't want to talk about it ((@&#^%^@($#&@#).

              One important reason to keep it all together is future changes/enhancements/upgrades. With more than one place to make changes, can you really be sure you changed them all? Though this may sound trivial, it can be a big headache (and I've found that those developers that are most confident that they can remember to change every app are the ones that are most likely to screw it up!!!) (no offense intended)


              • #8
                RE: input please! multi lots, protected

                Another reason to keep it all in one database might be that the salesmen will probably find themselves selling or transferring cars from other lots. You will want to make that process easy.
                Pat Bremkamp
                MindKicks Consulting


                • #9
                  RE: input please! multi lots, protected


                  Use the user login security to allow/disallow access to forms, reports, etc. We have a very complex application but the main screen interrogates the user security and enables/disables buttons for access. You can also hide buttons based on user security level. It takes a bit of script coding, but your life should be a little easier.

                  I also take some exception to the "one large application" theory. My "application" has literally 50 separate folders with applications specific to departments. If I were to combine everything in one large apd, Maintenance would be a nightmare. There are more than 1000 .dbf's and sets. Just trying to find a form to change it would be miserable. We have gone the route of having one main sign-in app that calls sub apps based on who you are and where you want to go.



                  • #10
                    RE: input please! multi lots, protected

                    If I were developing a large in-house database that would never run anywhere else I might consider multiple folders. But if I were developing an application that needed the slightest bit of portability, I would go the single folder route. I too converted a fairly large app from a5v1 that consisted of at least 10 different a5v1 applications ( different folders ) with several hundred+ tables and many sets. For timing reasons, we could not convert all apps simultaneously. We had to let some apps run on the old stuff until we got to them. I bit the bullet and put it all in one folder having to hunt down all the hardcoded references to the other folders. I don't want to do that again.


                    • #11
                      RE: input please! multi lots, protected

                      Seems to me there is scope for an enhancement in Alpha Five here...

                      The ability to somehow group tables and sets into smaller units than an adb. Maybe another field in the adb so you could have the "red", "green" and "yellow" groups, or the "payables", "recievables", "GL" group or whatever suits your situation. It is purely for developer convenience in finding your way through these very large adb's.

                      Keep it all in one folder, let the database compact run the whole shebang, let the hardcoding do it's thing, but allow sorting of tables and sets in the control panel for developer efficiency and sanity.


                      • #12
                        RE: input please! multi lots, protected

                        Thatis a very appealing idea.
                        Bill Hanigsberg


                        • #13
                          RE: input please! multi lots, protected

                          I now see the logic and am proceeding with no extra folders

                          Thanks folks, Great discussion