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

Moving (or restoring) a database to different drive / directory...

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

    Moving (or restoring) a database to different drive / directory...

    I've searched high and low here for info regarding this, yet I can't find an answer to the questions I am looking for...

    ISSUE:
    When you restore a database to a new directory, all references to the database objects still point to the original location.
    ie: tbl = table.open("tablename|C:\a5database\tablename.Dbf")

    SPECIFICALLY:
    This question especially pertains to code generated in action scripting. ~All table references point (explicitly) to the original file location.
    (A solution for all code, including functions and Xbasic scripts, would be beneficial too!)

    Is there a solution here?
    1.) I can't find any global search and replace. (I'm surprised there isn't one.)
    2.) How about some way to setup an alias before application creation. (That would be utilized even within action scripting.) ~I know an alias feature exists, but it doesn't seem to apply to action scripting.
    Last edited by SNusa; 02-06-2011, 01:53 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."

    #2
    Re: Moving (or restoring) a database to different drive / directory...

    ttt - Anyone?
    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


      #3
      Re: Moving (or restoring) a database to different drive / directory...

      Robert, the example you cite is not an action scripting statement.

      If you've hard coded the path into your xbasic code then yes, you're going to have change them one by one.

      The code to open a table in xbasic does not need to include the path, so long as the table resides in the same folder as the database libraries.

      i.e. tbl = table.open("Customer")

      the key to "portability" is to keep all elements of your database application in the same folder as the database libraries, and then refrain from hardcoding full paths in your code.

      Comment


        #4
        Re: Moving (or restoring) a database to different drive / directory...

        Originally posted by Tom Cone Jr View Post
        Robert, the example you cite is not an action scripting statement.

        If you've hard coded the path into your xbasic code then yes, you're going to have change them one by one.

        The code to open a table in xbasic does not need to include the path, so long as the table resides in the same folder as the database libraries.

        i.e. tbl = table.open("Customer")

        the key to "portability" is to keep all elements of your database application in the same folder as the database libraries, and then refrain from hardcoding full paths in your code.
        Tom,

        I realize what I presented is not native action scripting.
        I can't remember, but either I converted the action script to xbasic to modify it, or I was viewing the action script as xbasic. (too see what was wrong with the database that had been moved)

        Either way, this code is what was originally produced via action scripting.

        Hence, my question remains:

        Is there no way to setup a5 so that the action scripting uses relative references to data?

        And is there any way to perform a global search and replace for all instances of code in a5?
        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


          #5
          Re: Moving (or restoring) a database to different drive / directory...

          Robert

          Open the control panel to the tables/sets and put into detail view.

          Are all of the tables/sets in the same directory?

          Usually action script uses a5.get_path() to get the path name..
          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: Moving (or restoring) a database to different drive / directory...

            Originally posted by Al Buchholz View Post
            Robert

            Open the control panel to the tables/sets and put into detail view.

            Are all of the tables/sets in the same directory?

            Usually action script uses a5.get_path() to get the path name..
            Yes they are.....

            Taking into consideration automated code generated via the a5 genies (ie:action scripting):
            (Assuming you develop a desktop application, using dbf files, without hard coding any absolute file locations int Xbasic scripts.)

            "How portable are a5 desktop applications?"
            When using a5 "Backup & Restore", and the "Zipping Utility": Can you restore (from a backup) and UnZip (from a Zip) the database anywhere and to any drive? (ie: develop it on the D:\_dev\appname and then later use it on C:\_alpha5\appname)
            Same question goes for deploying a multi-user database application on a server... - Does the location of the database on the server have to "mimic" the location on the development computer?

            Another related question..... I know the server does not need to have a5 installed (for desktop applications) but what are the other requirements of the server? Could the database (dbf based) data be stored on a NAS? If so, must it be a Windows based NAS?
            (Obviously the users would need the a5 runtime installed on a windows OS, and then shadow copy the "non-data" files for usability / performance concerns.)
            Last edited by SNusa; 05-09-2011, 03:34 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


              #7
              Re: Moving (or restoring) a database to different drive / directory...

              Robert,

              When one manually restores a database you have the option to specify a destination that's different from the drive or folder where the database originally resided. Alpha Five will restore the database files to the specified location, and the new "path" to each component will be adjusted to the specified location automatically. The "old" path to the database files no longer appears in the "restored" copy. This of course makes the database "portable". (I'm assuming the entire database is originally located in a single folder, no subfolders or external folders are in play.)

              Here's a screencast that shows you the steps I'm using. Howare they different from what you are doing?

              http://screencast.com/t/NEWMJrjTiquB

              Comment


                #8
                Re: Moving (or restoring) a database to different drive / directory...

                Originally posted by Tom Cone Jr View Post
                Robert,
                Here's a screencast that shows you the steps I'm using. Howare they different from what you are doing?
                http://screencast.com/t/NEWMJrjTiquB
                Wow, thank you Tom. I'm not doing anything differently... Just wasn't sure.
                Hows FL? My girlfriend is visiting here folks in the villages right now. I had to stay here because of my occupation....
                I now know that backkup and restore resolve a5 coding to the correct path.
                (Providing was careful not to hard code paths (ie use: the A5.Get_Path() etc...)

                But what about zipping and un-zipping? I presume this does not make "path location corrections", right?

                And how about dropped tables & sets? Does backup and restore also resolve the code to a new path for items that have been dropped?
                I learned that I could duplicate a set (and then drop the original one so it was out of sight (along with it's associated form and event code on the form.)

                Doing so, give me some very unique and beneficial "versioning" control.

                Example:

                Lets say I have an invoice set name invoice_sv01 (which "resolves in my head" to: Invoice set version 01) ~This set also has an associated form frmInvoice...

                Now lets assume I wish to make revisions to my design....
                So I duplicate the set and give it a name invoice_sv02
                At this point, I have two sets invoice_sv01 and invoice_sv02 (along with two seemingly identical forms named frmInvoice, each attached to one of the sets above) displaying on the control panel.
                If I keep them both there, problems will develop as I assign script / action to events. (I know this from trial and error, as a5 tries to add identifiers to it's script.)

                However, by dropping the original table (invoice_sv01) which also drops the associated duplicate forms & objects, I have really stumbled upon a neat way to version track and rollback (if necessary) changes I make.... (I don't think too many a5 users know this can even be done, because I've never seen it mentioned anywhere!) ~I found this trick by "dumb luck" when I was developing file / table / variable / function & script naming conventions.

                The beauty of this is that the original version of invoice_sv01 (and the associated files such as forms etc.) are neatly "tucked away in case I mess things up and wish to revert the process. ~ And since dbf files are small in the development stages, it's not a big deal with regards to space..... I can keep them there indefinitely at little cost.....

                So the last question is: Even those objects are dropped, they are still available if necessary. I'm hoping that backup & restore effects all files in the db, including these "dropped items."

                Another thing I find peculiar is: Why is there no a5 deploy function? (A function that could "push" a database to it's final destination or even a server where it will be used? (Instructional videos leave me to believe developers resort to either ftp, zipping, or even drag & drop via windows remote desktop! "so 90's ish"
                Last edited by SNusa; 05-09-2011, 05:50 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


                  #9
                  Re: Moving (or restoring) a database to different drive / directory...

                  But what about zipping and un-zipping? I presume this does not make "path location corrections", right?
                  I don't think so. I regularly use 3rd party zip utilities to "move" all the files from a database folder to a different machine or drive. As long as the files defined in the database libraries are physically located in the same folder as the database libraries themselves, Alpha is smart enough to find and use them.

                  And how about dropped tables & sets? Does backup and restore also resolve the code to a new path for items that have been dropped?
                  Sorry, I don't know about this. Why don't you investigate and report back?

                  You might try "dropping" a table (or set), and then inspecting the database folder to determine if the table and its dictionaries have vanished. I think you'll find that they have not. They haven't been deleted, just dropped from the collection of files that make up the database. So, a 3rd party utiilty that grabs all the files in the folder and zips them up will include "dropped" tables (or sets). I would imagine the Alpha utilities do likewise, but wait for your confirmation.

                  Comment


                    #10
                    Re: Moving (or restoring) a database to different drive / directory...

                    Robert, I'm surprised that you are seeing those problems. I don't personally use action scripting at all but I do see a lot of code built by others using action scripting and I don't ever recall seeing any hard coded paths in it. Or at least very few.

                    As Tom hinted, if your dbf files are (or were?) in a different folder than your .adb file then A5 may hard code the path.

                    I have a lot of apps that are completely portable and will work from any folder with no modifications to the code. For me, this just isn't an issue.

                    As for a global search and replace, I have two comments.

                    (1) There is a global search and replace for anything in the Code tab. However, that doesn't help with code in your layouts - on buttons, field events, etc. - or in the field rules themselves.

                    But personally, I never this feature because....

                    (2) I consider global search and replace routines to be extremely dangerous and will not use them even on one script unless I've already done a manual search and replace on the same "item" and just want to make another change. Even then, I'm very likely to do it manually again just in case. I also will not build a global search and replace action in my applications for people to use on their data. It's just too danged dangerous. I've seen too many instances of people making changes that completely destroy the data/code. Sometimes it's just one unlucky "oh darn, I forgot that was there" but all too often it's because the user wasn't thinking. The real problem is when they come back to the developer without a backup and ask you to fix it. Sometimes, depending on the text being replaced, it can be impossible to do a reverse search and replace to undo the mistake. For a simple example, let's assume you wanted to change all occurences of "ei" to "ie". You can do it but then if you try to reverse it you are likely to find a lot of places where "ie" already existed and you would end up changing those also - and that's not what you wanted.

                    Here's an extreme example that really did happen years ago. The (rather new) developer decided to change all the uses of some one letter variable like "i" to something else like "counter" with a global search and replace. The result dcounterdn't work out too well. countert ended up makcounterng a real mess of hcounters code and he had to rebucounterld countert from an old backup that dcounterdn't have many of hcounters newer addcountertcounterons.

                    Also, ask yourself why Word doesn't have a global search and replace feature. Certainly they could have done it quite easily in something as powerful as that.

                    Comment


                      #11
                      Re: Moving (or restoring) a database to different drive / directory...

                      Originally posted by CALocklin View Post
                      Robert, I'm surprised that you are seeing those problems. I don't personally use action scripting at all but I do see a lot of code built by others using action scripting and I don't ever recall seeing any hard coded paths in it. Or at least very few.
                      Don't be, I'm not! I have this "crazy nack" (I used to call it a gift....) for finding bugs and oddities. Always have. (Accounting programs, pos programs, you name it. If there's a bug, I seem to find it..... I'v reported about 20 bugs over the years in my previous attempts to learn a5. 95% of them were acknowledges as legitimate bugs! (I found about 6 of them in v10.5 since February!) ~ Weirdest thing is, of all the thousands of users worldwide, at my capacity, why am I finding these? ~ I think it's again because of the way I learn. (trial and error, from the ground up.) Many experienced users aren't using the tools I use. They just go straight into writing Xbasic scripts. And very few "newbies" are really using the the tool from the ground up, the way it was originally designed..... (just my opinion)

                      I think many of the problems I experience have to do with how I approach "learning to use software tools in general." I learn the hard way. I'm not satisfied knowing simply that something works. I need to know "why exactly it works as it does." It's how I achieve "critical mass" with regards to my "learning curve." Learn it this way, it sticks with you for life. So I find myself digging around alot, trying to do things that most people wouldn't...... It becomes monotonous when you have to first establish whether it's you, or the software.

                      I definitely experience several strange things happening when moving databases..... As a matter of fact.... If you install the Alpha Sports demo, and try copying it (using windows explorer), lets say to a new drive and a new directory.... You will notice a few strange things begin to happen.
                      I can't remember exactly what they are. Nevertheless, several things (experienced while editing the forms in this new location) don't work 100% as they should. I have a suspicion that some of these issues have something to do with shared library items (or something similar) that a5 uses somehow. That's actually the basis of why I asked this question in the first place......

                      I do know that if you have a startup form (specified under file tab as opposed to using an autoexec script, strange things can happen to the code. (That's how I figured out the undocumented problem I encountered in the next paragraph.) I've also brought back dropped tables (which result in duplicate forms with the same name) wreak havoc with the coding generated by a5....
                      Incidentally, it's important that you don't use any strange characters like @ in any directory when you create a new database. (at least as the first character) It messes everything up!
                      (I back up my drives to a web based service. With the exception of Alpha (learned the hard way) everything I do not wish to back up is located in a top folder begining with the character "@." (Ie D:\@Downloads, are not backed up, but D:\Downloads are.....)

                      Learning this the hard way sure caused me some initial anxiety..... But I'll never make these same mistakes again! ;-)

                      I personally think it would be a great idea for someone to place a moderated "QUIRKS" (OK, call it "KNOWN ISSUES") section on this forum to help all users (new and seasoned) avoid the frustrations caused by known oddities such as this, index string truncation, long table name risks etc........
                      Having all the major "pitfalls" in one place sure would have helped me......
                      Last edited by SNusa; 05-09-2011, 09:56 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