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

Alpha Five compared to Access

  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    RE: Alpha Five compared to Access

    Hi folks
    Tom Cone Jr Are you saying that field rules defined for a table are disregarded if the table is linked to othes in a set?

    My error, then, erase that objection, and leave the others :-)
    Tom Cone Jr
    dBase files...The Alpha Five implementation is consistent with how its predecessors, from a variety of different publishers, did it.

    And this is one of the reasons that the dbase implementation was considered a little rinky-dink, and often languages only offer it as an auxiliary, like with a special driver, while seeking to use something like btrieve or a proprietary schema as their default.

    I do not agree however that differences in terminology are a valid basis for drawing conclusions about the integrity of the database engine, or the data which it is managing.

    There are three issues ..

    1) Data Integrity, which Alpha handles on the field rule
    level rather than the Index Level
    (with some difficulties, like when a child table
    prevented parent table data entry)

    2) Ease of implementation
    (a "Unique Index" in one place versus having to
    place it in each field)

    Using the term "Unique Index" for something that is not,
    by normal database methodology, is poor terminology..

    I agree that it isnt really fair to imply (1) from (2) or (3), the discussion sorta mixed the three...
    Tom Cone Jr wrote: ... differences in terminology are (not) a valid basis for drawing conclusions about the integrity of the database engine, or the data which it is managing.

    No, but when the terminology differences could lead to serious confusion, they are a valid topic as well....



    • #47
      RE: Alpha Five compared to Access

      I guess my overall feeling is that I would rather not see the two compared. I don't believe that Mr. Rabins and Alpha Software would be able to honestly prove that one is better than the other.


      The points that you, Marc and John made are all well taken and very well spoken. I would only suggest that perhaps from Alpha's standpoint, they are the proverbial mouse compared to the Microsoft/Access Giant. Thus, they may feel the need to draw comparisons and point out differences in their favor. The Alpha marketing effort is largely word of mouth and grassroots. They don't have the MS name recognition (obviously), nor do they have the financial means to compete head-on in an expensive marketing campaign (obviously). Thus, they attempt various best efforts to gain notice and market share. Given that reality, one can hardly fault them for doing all that they can.

      AlphaBase Solutions, LLC


      • #48
        RE: Alpha Five compared to Access


        I think it is valuable to point out differences. Where there are important features which are easily implemented in one product, and more cumbersome in another, that's also a valid point of comparison. I would also concede that no one tool is the perfect choice for every application. In my own work I find that if the tool of choice gets me there faster, producing accurate, reliable results, it will be used more often, even if extra steps have to be taken in a few narrow areas.

        It may surprise you to know that many of us don't use unique indexes at all. We generate and validate primary keys ourselves. Lots of other folks do just fine with the auto-increment field rule as a source of unique 'primary' keys. In either of these situations we have no need to define and use the sort of unique index filter you praise in other databases.

        I'm not qualified to judge whether the implementation of unique indexes in other products is 'better' than the choices available in Alpha Five's validation field rules. My gut tells me that if the other systems REQUIRE such a thing they're less flexible than Alpha Five.

        It also seems funny to me that our views of the last 20 years in microcomputing can be so different. We are both colored and shaped by our experiences! You seem to be suggesting that dBase formatted files are supported in 'modern' tools as something of an after thought. In my mind dBase is the granddaddy from whence all the the other microcomputer databases flowed. It's being supported because customers insist on it. Instead of working with a tool that stores your data in a proprietary format, Alpha Five uses a format that's MUCH more widely accessible. This distinction is far more important to me than the differences, if any exist, in alternative methods for assuring unique primary keys.

        -- tom


        • #49
          RE: Alpha Five compared to Access

          We shall see
          Marc King


          • #50
            RE: Alpha Five compared to Access

            Hi Tom,
            You make some good points here..

            >It may surprise you to know that many of us don't use >unique indexes at all. We generate and validate primary keys ourselves.

            True, I do the same in my mini-computer apps, since you want an informed msg and full control, rather than an operating system (0,1,2,3) type of message...(or we emulate auto-incrementing in code with a control file).. nonetheless, it can be very nice from a data integrity view to know that there "can't" be any duplicate keys, whatsoever, no workaround anywhere..

            And, since Alpha is meant to be a non-code tool (to a large extent) generating and validating keys in code sometimes goes against this paradigm a bit ..

            Also remember we are or were having some situations where the child field rules are or were triggering problems in the parent database data entry, and I ended up taking such a rule out.. then what? have to go to form-level field verifiation ? Do you see the difficulty there ? A more complex implementation has more places to go wrong (as also in the necessity to cover each field separately with the same definition)... a simpler paradigm has less to go wrong..

            Now, I still consider procedural programming code far easier to work with than PC event-driven code snippets, although maybe in time an ease of PC-code-use sense will come, of course this is not really just an Alpha question, as much as a Windows event-driven question. Although within PC-land this leads to a question of comparing the implementation of what I will call "code visibility" (e.g. Clarion compared to Alpha), this issue I believe is not understood so well.

            > Lots of other folks do just fine with the auto-increment
            > field rule as a source of unique 'primary' keys. In either > of these situations we have no need to define and use the > sort of unique index filter you praise in other databases.

            True, autoincrement keys are fine, when applicable, composite key uniques are usually outside that box..

            >I'm not qualified to judge whether the implementation of >unique indexes in other products is 'better' than the >choices available in Alpha Five's validation field rules. >My gut tells me that if the other systems REQUIRE such a >thing they're less flexible than Alpha Five.

            They don't .. they are, however, a bulletproof mechanism for data integrity handled at the OS or Language level

            > dBase is the granddaddy... Alpha Five uses a format >that's MUCH more widely accessible.

            .dbf files are very nice for their cross-language compatibility, you can be pretty sure that R&R or Clarion or Delphi can likely work with them .. one reason I avoided Filemaker was their proprietary format, and mixing data with programs, you are always in an import/export mode to get at the data.. I like the idea that if I develop an .app in Alpha, I may be able to use other tools, even languages, right on the live data... (with caution about two languages working at once :-)
            Suffice to say, .dbf files have always had pluses and minuses (one example, weak on avoiding data corruption, so a whole industry developed on repairing damaged .dbf files)
            All in all, they are a good choice, and the issue of how a language should overcome the .dbf lightness in indexes is complex, Alpha chose field rules to emulate unique keys, *maybe* a reasonable choice, but, even if so, please don't call non-unique indexes "unique", you are asking for trouble from newbies developing apps.. As I pointed out, the advantages of such a "unique" index are very limited, and really are simply a browse/report aid (i.e. summary field)

            I must admit that with all our hashing this out, and with all the strengths in "Expression Building" for uniqueness that Alpha managed to give the developer, (very strong stuff) I still am not fully comfortable with the lack of index-level control.. at the very least the implementation should be described better, e.g. in the structure/index sections.

            >This distinction is far more important to me than the >differences, if any exist, in alternative methods for >assuring unique primary keys.

            With some of the caveats above, I can accept that :-)


            • #51
              RE: Alpha Five compared to Access

              One issue that concerns me is documentation. Although what Microsoft puts out is nothing special, there are several Access "bibles" that have full accounts of every command and function with examples. Right now there is no single reference for A5V5. Now when I need to do something new, I start with the 4.5 User's guide, then look in the various V5 books and then read the build updates. I think there should be a single updated reference book.

              In the interim, why not do what Foxpro did many years ago, when they had several different books. They published a 50 page index that listed where each item was discussed in each manual. It wasn't the best, but it sures beats nothing. Ed


              • #52
                RE: Alpha Five compared to Access

                we are addressing this

                Stay Tuned Edward
                Richard Rabins
                Co Chairman
                Alpha Software