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

How would YOU do it ?

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

  • #16
    Re: How would YOU do it ?

    I personally do not use this method. However I have a "test" database that I opened, it exists on my C:\ drive. I ran that code I posted earlier in the interactive window. The only errors I get are related to the global variables that form is looking for but do not exist in my test database. Otherwise the form opens and I can see and navigate the records.

    I tested this in version 11 Developer, Build 3036-4040. I do not know why you are getting the error "not found".

    Marcel may still be on holiday. Besides others may have the same question and this may be beneficial to them as well.
    Andrew

    Comment


    • #17
      Re: How would YOU do it ?

      It's entirely possible to store both databases and all supporting tables for each in a single folder. This can be handy when the two databases need to "share" a common table. I've been doing this for years in an application originally written in vers 4.5 of Alpha Five. All that's necessary is to use separate names for each database, and then avoid duplicating table and set names (except where they're to be "shared").

      Comment


      • #18
        Re: How would YOU do it ?

        No disagreement with that Tom - but the Form MUST exist in whichever DB you open it. That's my point. And that was the original request as I understood it. Not to have ANYTHING extra residing in the various transaction databases and still be open whatever in the master records database.

        I commented on the statement
        "Aye, that code is how you open a form that is not in the current database."

        Opening forms with shared tables is fundamental to many apps of mine. I share also with other types of DBF database systems.
        Last edited by Ray in Capetown; 12-26-2012, 04:20 PM.

        Comment


        • #19
          Re: How would YOU do it ?

          Originally posted by Ray in Capetown View Post
          For me this doesn't open a form that is not in the current database
          Code:
          form.view("Cust@c:\drive_g\acdps\cust.dbf")
          ERROR: Not found
          where it is in another. Would be an interesting idea - can you explain how you have it working

          Besides why are we bothering when Marcel Onck is not.
          Come'on Ray... cut me some slack. It's Christmas.... not in SA?

          Comment


          • #20
            Re: How would YOU do it ?

            The reason why I asked this is, that sometimes it is handy to have something like "building blocks" from which you build your "package of functionality" by grabbing different databases that each deliver a part of the requested functionality.

            Furthermore, that does not have to be restricted to your own databases (of which you know how tables, forms etc are named) but assume the following:

            I take a specific database from Tom, which handles sales for a shoe salesman. He wants to extend his functionality. So I just add my database to it, which delivers that desired functionality. Now, we only would need to add "lines" from Tom's database to my additional database.
            This could be done by opening forms in different databases. It IS an option...... I simply do not see any other, do you?

            It would be nice if Alpha's control panel had somewhat more options. Like creating directories inside it. Then you could simply add a directory in the control panel at every section (tables, forms, reports, code) and insert the objects etc from the other database in it.

            I do not object to having all in one database, but I object to having it all on one pile. It does not help keeping an overview when the numbers of tables etc are adding up, and the systems are getting more complex.

            I guess this is all about "how to organize things in the best way".

            Comment


            • #21
              Re: How would YOU do it ?

              oh O K ! Slack it is then. BTW since when do real programmers stop for Christmas? But then I'm Jewish.

              This could be done by opening forms in different databases. It IS an option...... I simply do not see any other, do you?
              It could be done - if Alpha could open a form from another database. It can't.

              You can simulate that - A5.load() with some minor changes to make it seamless.

              Try it.

              Comment


              • #22
                Re: How would YOU do it ?

                To be honest I am not sure what part of this thread I am missing. I keep seeing the question of how to open a form from another database. I keep responding that this possible and have provided the code for how to do it. However I also keep seeing that you cannot do this. So I put together a sample database that has 1 table with 1 form. On the form is a button that will open the form from a second database.

                Either this is what is being asked for or I have missed the point completely.
                Attached Files
                Andrew

                Comment


                • #23
                  Re: How would YOU do it ?

                  Hi Andrew
                  I took a look, see and know what you have shown. You are referring to "opening a form using data from another database"

                  But remove the form from one database and try open it from the other - you cant.
                  I think its the symantics - in the sentence "open a form from another database" is meaning "open a form that is in another database, not in this one"
                  If you have a solution to that lets try.

                  Added:- the idea Marcel seeks as I understand it is a hierarchy, not to have to duplicate every form in every/any "higher layer database"
                  Nor code or anything else - just inherit all via some link to the database below.
                  Last edited by Ray in Capetown; 01-01-2013, 04:10 AM.

                  Comment


                  • #24
                    Re: How would YOU do it ?

                    Originally posted by Ray in Capetown View Post
                    I think its the symantics - in the sentence "open a form from another database" is meaning "open a form that is in another database, not in this one"
                    If you have a solution to that lets try.
                    Isn't that exactly what Andrew has demonstrated. Open the ADB_a adb. In it is one form, Frm_a. On that form is a button that opens Frm_b. Frm_b is no where to be found in the ABD_a database/project/workspace. It is in a completely different database/project/workspace ADB_b.
                    Tim Kiebert
                    Eagle Creek Citrus
                    A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

                    Comment


                    • #25
                      Re: How would YOU do it ?

                      CORRECTION !!
                      Andrew is 100% CORRECT.
                      Mindblowing I must add.

                      The statement made by me was not tested to the full extent of its implication.
                      -------------------------------------------------------
                      Last edited by Ray in Capetown; 01-01-2013, 07:03 AM. Reason: CORRECTION

                      Comment


                      • #26
                        Re: How would YOU do it ?

                        Originally posted by Tim Kiebert View Post
                        Isn't that exactly what Andrew has demonstrated. Open the ADB_a adb. In it is one form, Frm_a. On that form is a button that opens Frm_b. Frm_b is no where to be found in the ABD_a database/project/workspace. It is in a completely different database/project/workspace ADB_b.
                        WOW and huge apologies Andrew.
                        I was so obstinately stuck on the belief that the form was needed for this in the first place from that example.
                        I now cleared form and data from B. and then entered into the IW
                        Code:
                        form.view("frm_a@"+a5.get_path()+"\tbl_a.dbf")
                        and it opened.

                        So all you need in the current database is the code that knows where the form is.
                        That is - for me anyway - a revelation thanks for your persistence and Tim's
                        and again humble apologies. Next round is on me.

                        Comment


                        • #27
                          Re: How would YOU do it ?

                          No worries Ray. I am glad we are all on the same page. Now to broaden the scope some more. You can call scripts that exist in another database.

                          'Date Created: 02-Jan-2013 03:53:28 PM
                          'Last Updated: 02-Jan-2013 03:55:20 PM
                          'Created By : andy
                          'Updated By : andy
                          OPTION STRICT
                          OPTION ENCRYPTED_TOKENS
                          ON ERROR GOTO ERR_HANDLER

                          DIM vMsgC as C
                          vMsgC = "Hello world" + crlf() + a5.Get_Name() + crlf() + "This script is in database 'B'"
                          ui_msg_box("Hello",vMsgC)


                          END
                          '-----------------------------------
                          'Error handler
                          '-----------------------------------
                          ERR_HANDLER:
                          DIM vErrN as N
                          DIM vMsgC as C
                          vErrN = error_code_get()

                          vMsgC = "Error # "+ vErrN + crlf() + error_text_get(vErrN)
                          vMsgC = vMsgC + crlf() + "Script: " + error_script_get()
                          vMsgC = vMsgC + crlf() + "Line #: " + error_line_number_get()

                          trace.writeln(vMsgC)

                          ui_msg_box("Error", vMsgC,UI_ATTENTION_SYMBOL)
                          vMsgC = ""

                          END
                          Using the database copies uploaded previously copy this script into database "B". Save it as "Hello_World".

                          Then from database "A" execute this command.
                          script_play("Hello_world@"+a5.Get_Path()+"\adb_b.alb")
                          The biggest concern with this is that the script will run in the context of database "A". This is demonstrated by line 2 of the script " a5.Get_Name() " which will return the information related to Database "A".

                          To wrap it up we can call forms and scripts that reside outside of the current database. This is one method of achieving the results that Marcel was asking for.
                          Andrew

                          Comment


                          • #28
                            Re: How would YOU do it ?

                            Very interesting.
                            I just received the feedback - been without an ADSL line on and off for days, thanks to the sole telecoms carrier here, owned largely by govmnt, Telkom (there is a website Hellkom)
                            I will play around with it - yes that would largely cover his request.

                            Thanks
                            again.

                            Comment


                            • #29
                              Re: How would YOU do it ?

                              Originally posted by mronck View Post
                              Hi Andrew,

                              Yes, that is an option, but then you get one "organic" database. I understand that option. But I am looking for a more "slick" solution for instance where the master database would function as an add-on to the other databases or something like that. So you will not "cloud" the transparency/organizational structure from the transaction databases (the others) with the complexity of the "master" database. The control panel of Alpha Five is severally limited with regards to the organisational structure as is, and I am looking for options to add complete databases to one database without making it even more complex in the control panel by added tables, forms and reports. I do not know if it even can be done....
                              Originally posted by mronck View Post
                              The reason why I asked this is, that sometimes it is handy to have something like "building blocks" from which you build your "package of functionality" by grabbing different databases that each deliver a part of the requested functionality.

                              Furthermore, that does not have to be restricted to your own databases (of which you know how tables, forms etc are named) but assume the following:

                              I take a specific database from Tom, which handles sales for a shoe salesman. He wants to extend his functionality. So I just add my database to it, which delivers that desired functionality. Now, we only would need to add "lines" from Tom's database to my additional database.
                              This could be done by opening forms in different databases. It IS an option...... I simply do not see any other, do you?

                              It would be nice if Alpha's control panel had somewhat more options. Like creating directories inside it. Then you could simply add a directory in the control panel at every section (tables, forms, reports, code) and insert the objects etc from the other database in it.

                              I do not object to having all in one database, but I object to having it all on one pile. It does not help keeping an overview when the numbers of tables etc are adding up, and the systems are getting more complex.

                              I guess this is all about "how to organize things in the best way".
                              Bingo - I've had these exact thoughts, over and over again..... One thing worth mentioning regarding the mixing of databases are "missing variables." If you call the external form, and that form relies on any "global variables or higher" (declared elsewhere ie: not in that form or in the underlying tables/sets) you're going to need to add them back in. And the correct place (as I recall from testing/debugging a5) is NOT from within the code itself... They need to be set "at a higher level" via the "V" in the toolbar. If initiate/declare them them via a form event via code, you may experience issues, as they are not initiated "soon enough" for "a5 internals." I also suspect other things (such as saved queries etc. used in the form may present other issues.) ~ Regardless, without "building blocks" (as suggested above) built into a5 itself: I'll bet you'll encounter some strange and unexpected results at times!!

                              Incorporating both a"Building-Block modular design" & "Control Panel with directories" into a5 are great ideas by the way! The "a5 program" is way too complicated and has grown well beyond the present organizational limitations of the a5 CP. (Especially since the web components were "bolted on.")

                              Note: You can also place the two databases in two directories (parallel to one another @ the same level) to keep them organized & separate. But since a5.get_path() won't work in this instance, you'll have to either "hard code" or declare a variable to the path instead.
                              Last edited by SNusa; 01-05-2013, 11:18 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


                              • #30
                                Re: How would YOU do it ?

                                "Modularized Integration"..... I believe there is already a way to do this, built into a5!

                                Just had another idea.... how about using the dropping (and re-adding) of databases? You don't have to first "drop a database" to "add it" to a different database..... And you can "re-add" to your hearts content if necessary without fear of breaking anything.

                                Providing you have access to the existing database (aka original "component"), unless I'm missing something - This is all you'll need (presumably) to do.....

                                1.) Develop the new database "component" up to the point where it needs "integration."
                                2.) Now "integrate it" by doing the following.
                                • Copy this "new component" (the entire database directory) into the "original component" directory. (so the "new database component" is self contained in it's own directory)

                                • Open the "original component" and from the table/set tab, select "Add Table." (find the new table in the "new database component" directory ~ the warnings should not apply.)


                                BAM! ~ I think it may be as simple as that! As for functionality I'll bet this is also a good way to "modularize integration!" (But check with "the pro's" first.)

                                Modularized..... And the best part is (as far as I can tell) is: Any changes you make to the "new database component" can be made either from the "original database" or from the "new database component!!! (This includes new browses, forms, reports, tables, etc.) Because when creating & editing objects based on "added external tables" (from within the new database) you are actually making changes into to the "new database components!" (I'm not suggesting doing any of this without checking with AlphaSoftware first though!)

                                The only "caveat" here is scripts. Scripts (created under the "new database") will have to be imported for use in the new "original database." (But Alpha has made that a straightforward and simple process.) Also, when writing scripts, using relative paths & at in all cases, avoid "hard-coding" so that at least your "new components" are designed "portable" from the get go....

                                Note: I also suppose it might be possible (in certain instances) to switch things around and make your new database the "root" depending on the circumstances. ~ But only if you're "building something big" around something that is presently "small and simple." I particularly don't like the thought of moving the original directory, even if everything else worked. ~ Because based upon prior experimentation, it would be like "playing with fire!" (I submitted several confirmed and fixed bugs regarding "hard-coded" directory/file structure bugs over the past few years.)

                                PS: A year or so ago, I did some extensive "testing" with the "drop and add tables" features/capabilities. I came to the conclusion that this great feature is one of the least understood (and utilized) capability built into a5! (It is also a fabulous solution for creating multiple comprehensive [virtually "one-click" restore-able] versions of tables/sets (along with their associated underlying objects like forms & reports etc.....) The only problem is that when you use the internal backup/restore functions like (zip, export and backup) from the a5 menu, they all ignore dropped tables.) Apparently they work under the assumption that a dropped table is: "JUNK!") ~ So I use different 3'rd party "zip" tools for backups. This is a relatively SIMPLE FIX that could be addressed by adding one persistent checkbox (in these routines/tools!)
                                Last edited by SNusa; 01-06-2013, 12:10 PM.
                                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