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

Announcement

Collapse

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

Multiple users with multiple databases

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Re: Multiple users with multiple databases

    Originally posted by jbk View Post
    Peter G, sorry for the inconvenience I have caused you. I'm obviously new at this and was simply asking for some "professional" direction.
    It's not an inconvenience. With respect to my comment to Stan ("You make it sound so easy"). I was poking fun at myself - because, Stan gave you the best answer (at least I think he did) - direct & straightforward and better than my original generic suggestion. Just go to the controlpanel's operations tab and create a new operation. Obviously some trial and error and exploration is required on your part. Like Stan said, the Genie will guide you through it. I wasn't trying to give you a hard time.
    Peter
    AlphaBase Solutions, LLC

    [email protected]
    https://www.alphabasesolutions.com


    Comment


      #17
      Re: Multiple users with multiple databases

      David K, thank you for your response. I fully understand what and how to do what you have suggested. Instead of have "unique" databases for each salesperson on the main computer, I would like to have each sales person's data merged on a weekly bases to ONE database without interfering with previous data, therefore anyone on the main (office) computer can lookup a customer say by there city and all customers (no matter who the salesperson) would be displayed. The salesperson on there laptops would only have there data, but the office computer would have all 6 salespersons data. I would like to make it as easy as possible. A office worker may have to lookup a particular customer and may not know who the customer's sales rep is, this way they would simply type in the customer's business name and data would be displayed.

      Comment


        #18
        Re: Multiple users with multiple databases

        Peter G, thank you....

        Comment


          #19
          Re: Multiple users with multiple databases

          Jon,

          Although a web based app may be the ideal, it seems you do not want to go down that road (and I am not sure I would either if your aim is simplicity and low cost). In that case, Stan's advise is what I would follow up on. If at the main office side you do an import to a just zapped temp file and then an append operation set to check for duplicates and replace existing records in your existing main office table, you would not even have to worry about whether you are sending just new records (unless file size gets too large, in which case just send the new ones determined by whatever). In this scenario the key part of what you need can be done with Genies in the operations tab.

          A bit more detail: The "just zapped temp file" can be an empty duplicate of your main file, probably without fields rules if the main file has any. Why not just import directly into the main table? Two reasons: 1) If there are problems in the middle of the import, there is no risk of messing up the main table; you can always zap the temp file and start over, no harm, no foul, and if data makes it into the temp duplicate of the main table, there is almost no chance of the subsequent append running into problems. 2) Appending from the temp file to the main table allows you to check for duplicates and update old records with new, updated data--you can't do this with a direct import.

          Virtually everything in this scenario can be done with either built-in operations (e.g., duplicating the main table), Genies in the Operations tab, and Action Scripting (e.g., zapping the temp and then running the import and append operations) on buttons of forms or even in an autoexec script. Very simple, easy to build and test and low cost. Which I suspect is what you are looking for!

          Ray Lyons

          Comment


            #20
            Re: Multiple users with multiple databases

            Originally posted by jbk View Post
            David K, thank you for your response. I fully understand what and how to do what you have suggested. Instead of have "unique" databases for each salesperson on the main computer, I would like to have each sales person's data merged on a weekly bases to ONE database without interfering with previous data, therefore anyone on the main (office) computer can lookup a customer say by there city and all customers (no matter who the salesperson) would be displayed. The salesperson on there laptops would only have there data, but the office computer would have all 6 salespersons data. I would like to make it as easy as possible. A office worker may have to lookup a particular customer and may not know who the customer's sales rep is, this way they would simply type in the customer's business name and data would be displayed.
            Sorry... didn't mean that separate databases be kept at the Central office.

            "Update Databases" would be emailed to head office.
            A person would attach to the Update database, transfer the information, then drop the tables.
            The "Update" database would be stored in a folder unique to that salesperson, just to keep them separate from other people.

            The information from each salesperson would be transfered to the central database.

            Comment


              #21
              Re: Multiple users with multiple databases

              Originally posted by Raymond Lyons View Post
              Jon,

              Although a web based app may be the ideal, it seems you do not want to go down that road (and I am not sure I would either if your aim is simplicity and low cost). In that case, Stan's advise is what I would follow up on. If at the main office side you do an import to a just zapped temp file and then an append operation set to check for duplicates and replace existing records in your existing main office table, you would not even have to worry about whether you are sending just new records (unless file size gets too large, in which case just send the new ones determined by whatever). In this scenario the key part of what you need can be done with Genies in the operations tab.

              A bit more detail: The "just zapped temp file" can be an empty duplicate of your main file, probably without fields rules if the main file has any. Why not just import directly into the main table? Two reasons: 1) If there are problems in the middle of the import, there is no risk of messing up the main table; you can always zap the temp file and start over, no harm, no foul, and if data makes it into the temp duplicate of the main table, there is almost no chance of the subsequent append running into problems. 2) Appending from the temp file to the main table allows you to check for duplicates and update old records with new, updated data--you can't do this with a direct import.

              Virtually everything in this scenario can be done with either built-in operations (e.g., duplicating the main table), Genies in the Operations tab, and Action Scripting (e.g., zapping the temp and then running the import and append operations) on buttons of forms or even in an autoexec script. Very simple, easy to build and test and low cost. Which I suspect is what you are looking for!

              Ray Lyons
              Lost my ability to edit the above, so let me add that I was talking about importing a text file (or maybe excel) on the presumption that for emailing a text file would be smaller (zipped or not) than a table, much less an entire database. In any case you may want to encrypt and/or password protect files sent as email (easy to do with zips, I believe) and of course tables can be encrypted in A5 (maybe text files can too?).

              But if you were to decide to use an A5 table, I would use the A5 table duplication ability to make it an exact duplicate of the main table (different name) and then you could skip importing to a "temp file" as described above and just run an append as described. Were it me, I would still import it into a temp file just in case the table gets fouled up in transit over the Internet (for the reason described in the above).

              Ray Lyons

              Comment


                #22
                Re: Multiple users with multiple databases

                Here's a neat idea....
                Why are you messing around with zipping, copying, sending etc...

                Why not just create the application to use native a5 database based tables while they are on the road to collect the data.

                But also have (in office) main active link tables (ie. MS sql Server) which can be connected to as needed through a simple append query? (Using the AlphaDAO connection along with the new features available in a5 v9.)

                Then all your sales guys have to do is connect the pc to the network (via cable or wireless) and press a button. "BAM" the data uploads (merges) into a single database in the main office.

                What you want to do sounds like a perfect fit for the new capabilities in a5 v9. If you want to go the free way (for the back-end database) I believe you can still use mySQL absolutely free. (instead of MS sql Server)

                As long as a5 doesn't try to connect to the back-end database (until the user asks for it) I would think this would be a neat solution that makes it simple for the sales guys to use!

                I'm kind of a rookie here with a5, thus additional feedback from "Certified AlphaHolics" would be a good idea.

                But I think you could put the whole update thing together with only a bit of active scripting, and probably no x-basic coding whatsoever.

                And as for the benefits... All that data sitting in an industry standard relational DB...
                Forget about obsolescence and connectivity issues!
                Last edited by SNusa; 02-26-2009, 01:21 AM.
                Robert T. ~ "I enjoy manipulating data... just not my data."
                It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                Comment


                  #23
                  Re: Multiple users with multiple databases

                  Originally posted by SNusa View Post
                  Here's a neat idea....
                  Why are you messing around with zipping, copying, sending etc...

                  Why not just create the application to use native a5 database based tables while they are on the road to collect the data.

                  But also have (in office) main active link tables (ie. MS sql Server) which can be connected to as needed through a simple append query? (Using the AlphaDAO connection along with the new features available in a5 v9.)

                  Then all your sales guys have to do is connect the pc to the network (via cable or wireless) and press a button. "BAM" the data uploads (merges) into a single database in the main office.

                  What you want to do sounds like a perfect fit for the new capabilities in a5 v9. If you want to go the free way (for the back-end database) I believe you can still use mySQL absolutely free. (instead of MS sql Server)

                  As long as a5 doesn't try to connect to the back-end database (until the user asks for it) I would think this would be a neat solution that makes it simple for the sales guys to use!

                  I'm kind of a rookie here with a5, thus additional feedback from "Certified AlphaHolics" would be a good idea.

                  But I think you could put the whole update thing together with only a bit of active scripting, and probably no x-basic coding whatsoever.

                  And as for the benefits... All that data sitting in an industry standard relational DB...
                  Forget about obsolescence and connectivity issues!
                  While on the road I was assuming they would use an A5 Db using dbf tables. When you say "Then all your sales guys have to do is connect the pc to the network (via cable or wireless) and press a button. "BAM" the data uploads (merges) into a single database in the main office." it sounds like you mean when they come back into the main office--assuming they all do that. But if that is the case, you do not need to use anything but dbf tables--unless you just want to for some reason. The one button "BAM" thing is just as easily done with Genie based saved operations and a few simple Action Scripts--no Xbasic required at all. On the other hand, yes you could effectively do the same thing with an MS SQL or MySQL database and Alpha Five. But unless you are talking about huge files or some other ????, I don't think that is what I would recommend. And yes, I have done quite a bit of work with Alpha Five and MySQL, so it is not as if I am stuck with doing things the "old" based dbf way. By the way, I could be wrong, but this sounds like a commercial use and I do not believe it is legal to use MySQL for commercial purposes. And MS SQL is not exactly cheap.

                  Raymond Lyons

                  Comment


                    #24
                    Re: Multiple users with multiple databases

                    Wasn't sure about the cost of mySQL in a business environment. I thought I remembered reading (years ago) when I was interested in possibly going down that road (which I didn't) that there was a free version (without support) for business use. I may have been wrong, and that may have changed also. (As mentioned above, I never went down the mySQL path due to it's limitations at the time.)

                    The reason I was thinging about a relational DB such as sql Server is the way you can remotely connect to it (at least I think you can with a5) using the connection strings right over the internet. (ie: the sales rep is sitting at a coffee shop 1500 miles away, and minutes later, the data is current at the home office.

                    I just thought that would be a neat client / server scenario where it is so easy and convenient to "merge" the data. Consequently, the users would be much more likely to "keep the back end up to date." And with multiple sales reps, I'd suspect that will be an issue.

                    Sure, setting up tables in MS sql Server takes a bit more work. But for just basic tables, it's no more difficult today than MS Access was a decade ago. (IMHO) And in a business enviornment where multiple sales reps are involved, spending a few hundred bucks for MS Small Business Server (which includes MS sql Server) is chump change in the great scheme of things.

                    Also, you are no longer exclusively limited to just working with a5, which obviously opens up endless possibilities. (Again, IMHO.)

                    Regardless, it was just an idea. I've been watching the "training videos" and working with MS sql Server. I'm amazed at how easily a5 appears to connect (and work) with "the heavy hitters" in the relational DB world.

                    This "fully functional" connectivity (via active links) is what finally got me on-board with a5 after all these years (back to 1996) of purchasing but only "tinkering" with the a4 - a5 product line. I strongly believe that this feature in a5 is key to the products future viability.
                    Robert T. ~ "I enjoy manipulating data... just not my data."
                    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                    Comment

                    Working...
                    X