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

A4 to A5 Database Info

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

    A4 to A5 Database Info

    Have recently updated from A4 to A5. We were getting misinformation in our reports & forms. It seems that records we had deleted from our A5 client table were not deleted from the A4 client database (that we imported the records from when installing). A5 was incorporating the A4 database information. We ended up duplicating the client table in A5, copying the field rules, indexes, libraries, etc. - but not copying the records. We then appended the records from the original A5 table to the copied database and deleted the original table (which was based on A4 records). The deletion process also eliminated the A4 database. This cleared up the problems we were having in our reports, etc. We renamed the newly created A5 tables to their original name. You can check to see if the records in your A5 tables are A4 or A5 based by right clicking on the table and go to properties. This cleared up the problems we were having.

    #2
    RE: A4 to A5 Database Info

    Hello Fancy:

    I had a hard time following everything you wrote. I have the impression you were simply trying to tell us how you solved your problem. Is that correct?

    Let me add something else that might prove beneficial down the road. You do NOT import dbf files from A4 to A5, they work seamlessly. In other words, if you have a DBF file in your A4 application, you can open it directly from A5.

    Of course you will then have to create brand new forms, field rules, queries, reports, etc. because nothing else transaltes from A4 to A5. But once again, let me state there is no import involved because the A4 dbf file is the only object that carries over seamlessly to A5.

    One other point, make sure all of the files for your new A5 application are stored in only one folder. If you scatter your files around in different folders, you are asking for trouble.

    Robert T

    Comment


      #3
      RE: A4 to A5 Database Info

      Robert -
      Yes, I was trying to tell anyone who may have had similar problems how we solved them, though not very well. I used the incorrect term "import". At A5 set up, we used the green plus sign to attach(?) to our A4 dbf files, we created new forms, field rules, etc. As we were changing/udating information in A5, we could not find some of the new records we had just entered (and saved) and were getting records on our report that we had deleted. It was bizarre! I went back to A4 to see if the records had changed there - and found the deleted records still there - and some double records from re-entering the info we could not find in A5. That is when I went to check the properties in my A5 table and found that it was using our A4 records. When we duplicated the A5 tables and appended the records from the copied A5 table - our reports finally printed the correct info. I don't know why this was happening (in more than 1 table), but we have changed all of our tables to have A5 properties and deleted the tables that had A4 properties and have not had any problems since.
      I currently have a love/hate relationship with A5 after working with A4 for years & years. Love what it does - hate trying to learn it (the hard way, of course!)
      Thanks -Donna

      Comment


        #4
        RE: A4 to A5 Database Info

        Donna;
        I think the reason for your problem in A5 with "deleted" records from A4 has to do with different procedures that the 2 programme perform. In A4 when you "delete" records, they are not "really" deleted ... they are just "marked for deletion". It is only when you "pack" the database are they really deleted. Before you pack, they are still there and can be undeleted. In A5 when you delete them ... you delete them.

        Duncan

        Comment


          #5
          RE: A4 to A5 Database Info

          Donna

          If I read your note properly, you have Alpha 4 and Alpha 5 both looking at the same tables(ie A4 databases).

          If so, you shouldn't. Put the Alpha 5 data in it's own directory and keep the Alpha 4 data in it's own and separate directory.

          There are some underlying differences that force you to do this.

          If I mis-read your statement, keep this in mind so you don't do it in the future.
          Al Buchholz
          Bookwood Systems, LTD
          Weekly QReportBuilder Webinars Thursday 1 pm CST

          Occam's Razor - KISS
          Normalize till it hurts - De-normalize till it works.
          Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
          When we triage a problem it is much easier to read sample systems than to read a mind.
          "Make it as simple as possible, but not simpler."
          Albert Einstein

          http://www.iadn.com/images/media/iadn_member.png

          Comment


            #6
            RE: A4 to A5 Database Info

            Duncan

            In A5 when a record is deleted, it still exists until the table is packed, just like A4. It is just a little harder to find.

            Jerry

            Comment


              #7
              RE: A4 to A5 Database Info

              Jerry;
              Thanks for the correction ... obviously A5 is not my specialty!

              Thanks,
              Duncan

              Comment


                #8
                RE: A4 to A5 Database Info

                Jerry-
                When you pack A5, does it also pack A4 at the same time?
                Donna

                Comment


                  #9
                  RE: A4 to A5 Database Info

                  Donna

                  Please refer to my other note.

                  Alpha 4 and Alpha 5 should not be pointing at the same data files.

                  Therefore packing by one program would not pack the data looked at by the other.
                  Al Buchholz
                  Bookwood Systems, LTD
                  Weekly QReportBuilder Webinars Thursday 1 pm CST

                  Occam's Razor - KISS
                  Normalize till it hurts - De-normalize till it works.
                  Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
                  When we triage a problem it is much easier to read sample systems than to read a mind.
                  "Make it as simple as possible, but not simpler."
                  Albert Einstein

                  http://www.iadn.com/images/media/iadn_member.png

                  Comment


                    #10
                    RE: A4 to A5 Database Info

                    Al,

                    I am still working with A4 but have some databases at home that I use A5 for.

                    I must say that any project that is fairly simple A4 is one heck of a lot easier to use and get results from.

                    Having said that I was thinking of trying to use A5 for some of the reports for A4 data and was wondering what sort of scripts to use to try and keep two sets of data in synch.

                    Has anybody had any success in this area?

                    Steve

                    Comment


                      #11
                      RE: A4 to A5 Database Info



                      Steve Pick wrote:
                      -------------------------------
                      Al,

                      I am still working with A4 but have some databases at home that I use A5 for.

                      I must say that any project that is fairly simple A4 is one heck of a lot easier to use and get results from.

                      It is usually the case that it is easier to use the system that you are most comfortable with. Once you rethink/relearn to use A5, you'll find it easier than A4.

                      Having said that I was thinking of trying to use A5 for some of the reports for A4 data and was wondering what sort of scripts to use to try and keep two sets of data in synch.

                      Has anybody had any success in this area?

                      If the A4 system is that simple, consider moving it all to A5 and going on from there. Unlearning and then relearning is hard enough. Trying to juggle two systems is harder.
                      Steve

                      I hope this formats properly with the Use HTML checked and the HTML tags in the body of the text. We'll see....
                      Al Buchholz
                      Bookwood Systems, LTD
                      Weekly QReportBuilder Webinars Thursday 1 pm CST

                      Occam's Razor - KISS
                      Normalize till it hurts - De-normalize till it works.
                      Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
                      When we triage a problem it is much easier to read sample systems than to read a mind.
                      "Make it as simple as possible, but not simpler."
                      Albert Einstein

                      http://www.iadn.com/images/media/iadn_member.png

                      Comment


                        #12
                        RE: A4 to A5 Database Info

                        Steve:

                        Alpha Five uses a totally different paradigm that gives you much greater flexibility and power. As usual in life, increased complexity comes along with that added power. However, once you figure out how it works, you may never want to go back to A4.

                        Many current A5 users worked in A4 many years and we didn't want to give up our tried and true DOS apps. Most of us changed reluctantly, not because we wanted to, but because we saw the future. Now we have so much power at our fingertips that sometimes I find it almost unbelievable.

                        Anyway, let�s return to your question. The only thing that translates seamless from A4 to A5 is your data files [dbf]. You will have to create brand new forms, reports, queries, scripts, etc. Why? Because as stated above, the A5 paradigm [Windows] is very different so your DOS tools do not work well.

                        Unlike DOS, in the world of Windows you can, and often have multiple tables open simultaneously, doing work in the background. When you're an A4 user, it feels oh so complicated and unnecessary. However, once you realize the potential, you will fall in love with A5 and your A4 apps will become a faint, but pleasant memory.

                        Robert T

                        Comment


                          #13
                          RE: A4 to A5 Database Info

                          Robert,

                          As I said, I have tried various A5 databases,

                          Address books, medical records, tape cd collections, soccer teams. I have them at home and each time I try to get information from them I curse.

                          I understand all the power of a5. Unfortunately, for the USER, rather than the developer, the single tasks that one can do on the fly are soooo much easier to do in A4 that if I want some information quickly I go to A4.

                          One can get get so much information from a database WITHOUT scripts just by using a SEARCH by or a join and a report. For information, an A4 report is so much faster to create than screwing around with A5. NOW, if one wants to send a professional looking report to somebody else then that is another story.

                          In the case above I was not looking for the QUICK and dirty reports that I often use on the fly but a more complex report and I understand that A5 is much more able.

                          Unfortunately, I have some 40 or 50 tables and sets, or more with some 90 MB of data at work in A4, with many field rules, reports and scripts in A4 that I don't have the 3 months or so to take off and dedicate my life to designing the same thing in A5. I actually USE the data every day.

                          Also the network has W3.1, W95 W98 machines. I didn't think A5 performed too well in that environment.

                          Why would I want to spend money replacing these when they work OK except for the odd report that I would like in A5.

                          We try not to waste money when we don't have to.

                          I appreciate all the words of wisdom but when I read messages on the A5 board of patches going haywire, DLL breeding like there was no tomorrow, I feel justified in slowing down the approach of adopting A5.

                          I would still like to try and create the odd report and work in A5 using the A4 data that I have.

                          Steve

                          Comment


                            #14
                            RE: A4 to A5 Database Info

                            Steve:

                            You wrote:

                            [Why would I want to spend money replacing these when they work OK except for the odd report that I would like in A5.]

                            That's a very good question, why would you want to replace them? If A4 is doing the job then stick with it. Nobody is trying to convince you it's time to change because A4 was a fabulous database for the world of DOS.

                            All I'm saying is if you want or feel the need to change, moving from A4 to A5 is in my opinion, far harder than for someone who was not an A4 [DOS] user.

                            And as I said before, the above means transitioning from one paradigm to a totally new and different one. Most people in that position [and I've been there] don't want to go through that process because they're perfectly happy with A4. Who wants to learn a series of new techniques all over again now that you have the DOS version working to perfection?

                            I always tell people if you're happy with Alpha Four and it does what you need, then stick with it. However, if you run into that proverbial wall where you cannot do what you want, then it's time to think about the transition to A5. Yes, it's a difficult one, but once you make it through the process where you finally understand how and why it works so differently from the DOS product, then it's clear sailing.

                            From that point on you will have a level of power and flexibility you couldn�t even begin to dream of with A4. And you know what else, it�s also tons of fun because you can do so many different things that you will never look back at the world of DOS.

                            Robert T


                            Comment


                              #15
                              RE: A4 to A5 Database Info

                              Steve,

                              While most would agree that 'using' a Windows app is often easier and more intuitive than 'using' a DOS app, designing new custom applications in Windows is exponentially more difficult than designing a similar app in DOS.

                              When you get ready to build your first, compare Alpha Five to the other database development tools in the same price range. Don't compare the work required to your DOS tools. It's not a valid comparison cause you've switched environments.

                              -- tom

                              Comment

                              Working...
                              X