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

Database Design Thoughts, Help!

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Re: Database Design Thoughts, Help!


    Even though Larry wants you to use SQL, there's no great way to use it on the desktop. Active-link tables are kluge. That leaves you w. xdialog (fast!) or WCD. I just finished a small xdialog project using MySQL (fast!), but super-labor intensive. You have to code EVERYTHING! And WCD (w. sql) will be slower on the desktop than dbf.
    AlphaBase Solutions, LLC


    • #17
      Re: Database Design Thoughts, Help!

      In my initial response, I didn't realize it was a desktop app. From a purely database design perspective, I believe SQL outperforms a regular DB, especially when the db size gets large.

      But since I discovered it was a desktop app some panels back, I have taken myself out of the discussion because I don't know Alpha Desktop apps, so I'm not the best person to help here - and I agree that using passive or even active link tables is not the best way to go.


      • #18
        Re: Database Design Thoughts, Help!

        These are interesting thoughts and I would have to think about how to implement this because I need a years worth of active history. for a years worth of data I have about 5000 reservations and 10,000 arrival and departures. One of my primary reasons for wanting to take a different approach is to put both the arrival and departure on on record. Much of my index creation problems stem from the fact that I need to compare the arrival and departure to see if services were performed when they got here or when they left and also to determine the time between them to indicate that to personnel that services are not done twice (which has happened before). I went through so many ways to try to easily do this, but I ended on filtered indexes which I think cause me latency issues as well as corrupt indexes from time to time.

        With the new structure, I would have the arrival and departure info in one record and all the services as a one to many. It would be easy to see all the services that have been ordered, I can apply a cost to each one and create an invoice, and basically seems like a better and more logical structure. My issue is still how to live summarize a status field for each type of service for a particular day.


        • #19
          Re: Database Design Thoughts, Help!

          Hi John,
          I am not sure what you mean by live summarize a status field, but wouldn't a post field rule in the various tasks you have do it?

          Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford


          • #20
            Re: Database Design Thoughts, Help!

            I thought about posting but I need to check the value of the target db, because there may be more than one service and I have to post the lowest status. I am using 1-4 for the status with 4 being complete. I want the status to indicate the worst case for that item. There may be multiples of the same service and I do not want to mark that service complete and overwrite one of the same types of service that has not been done. For example someone calls and says add a QT of oil to the left engine then call up later and request another QT for the same engine. Another rub which I am trying to figure out is that some services can happen both on arrival and departure, i.e. someone will want fuel on departure but not on arrival. So I need to add a selector on the Service as to when, however, then I need a way to "scan" the child records for the reservation and pull out the status's for each service AND which services for arrival and departure.

            I have used Max and Min and count for child records before and those methods are quick. If there is a way to do things like max or min on filtered child records, this would seem fairly quick as there are relatively few child records per reservation and the set has already identified the linked children.


            • #21
              Re: Database Design Thoughts, Help!

              On your screenshot, you show what looks like little list boxes for services that are empty - are these where a particular record selected will show what services have been done?

              Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford


              • #22
                Re: Database Design Thoughts, Help!

                If separate tables for income and outgo, then a header with connections to both are in order.

                I have not seen your structure, But when you start talking about using indexes to control something, there is a problem somewhere.
                Dave Mason
                Skype is dave.mason46