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

shadow copy, client overwrote server

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

    shadow copy, client overwrote server

    We've recently started using A5 in a network environment. A shadow copy process on one of the client machines (A5 runtime) seemed to have effected some change on the server. The paths to the tables on the server were X:\A5V5\... and after the shadow copy were C:\Program Files\.... effectively breaking everything.

    Since I can't pin down what exactly went wrong, I'm hesitant to trust shadow copy. Is this something that's preventable. Any ideas?

    Also, the whole adblock file removal trick is disconcerting.
    Is networking on A5V6 more reliable?

    #2
    RE: shadow copy, client overwrote server

    Don't be quick to thnk it's the shadow copy feature that's the cause more often than not, the problem is due to programmer error.

    If we knew more about how you're setup,someone could be more specific.

    kenn
    TYVM :) kenn

    Knowing what you can achieve will not become reality until you imagine and explore.

    Comment


      #3
      RE: shadow copy, client overwrote server

      Just trying to figure this out, before I tell the users they can refresh the shadow copy when prompted.

      1 server win2k A5V5, 8 clients w2k A5V5 runtime
      The networked drive where A5 is located on the server is X:

      When I performed the the shadow copy on a clean A5 runtime install, I opened the db on the server (X:\A5V5\db..). I went to net op. and selected create shadow... Selected the local path c:\progr... for the copy dest. and after copying some files (blue bar scrolled by a few times), it gave me an alert box "unable to write"....

      The 5 previous shadow copies on 5 other machines went smoothly and so have the rest.

      I haven't written any code regarding shadow copy in any apps and I especially haven't written anything that would/should influence the table paths.

      Is shadow copy a "pull" only process from the client? Can the adblock file interfere with the creation of a shadow copy?

      Comment


        #4
        RE: shadow copy, client overwrote server

        James Roberson wrote:
        -------------------------------
        Is shadow copy a "pull" only process from the client?


        Yes.




        James Roberson wrote:
        -------------------------------
        Can the adblock file interfere with the creation of a shadow copy?


        What do you mean by "adblock file?"
        Aaron Brown
        Alpha Software Development Team

        Comment


          #5
          RE: shadow copy, client overwrote server

          .ADBLOCK A temporary file used to prevent more than one user from refreshing a shadow database at one time. Cannot Refresh Database Problem
          There can be only one.

          Comment


            #6
            RE: shadow copy, client overwrote server

            Found the complete citation in the .chm...

            Cannot Refresh Database Problem

            When Alpha Five is refreshing a shadow database, it creates a file named after your database (.ADB file) by appending "LOCK" to the filename. For example, if your database was named INVOICE.ADB, Alpha Five would create INVOICE.ADBLOCK. The reason is to prevent more than one user from refreshing the database at the same time. When the refresh is complete, Alpha Five removes the file.

            However, if someone starts the process and does not finish it, Alpha Five may not erase the file. The result is that you get the incorrect message that someone else is refreshing.

            The solution is to delete the .ADBLOCK file (not the .ADB file).
            There can be only one.

            Comment


              #7
              RE: shadow copy, client overwrote server

              It sounds like you've run into the same thing I've seen but never been able to reliably duplicate.

              On one application the refresh shadow did not run to completion for some as yet unknown reason. When this happens (at just the right point in the process - whatever that is?) it seems as though the shadow .adb file is left on the server and overwrites the real .adb file. This is what causes the problem of looking for the files in the wrong place.

              Before seeing this thread, I assumed I was the only one who had ever seen this. My guess was that my startup methods were more complex than most and I had managed to somehow create just the right combination to cause the problem.

              Since my original installation file has the original .adb file, it is very easy for the customer to re-install it. (I use a third party installer and have the installation routine set up so it will never overwrite the data but will always overwrite the data dictionary files - a.k.a., the application files. This makes for easy re-installs and easy updates.)

              The only thing I can say for sure is that this only happened with applications that had long, complicated autoexec scripts and/or OnInit scripts in the run-on-load form.

              I was able to repeat it on my system but I could never pin down the exact cause so I wasn't able to tell Selwyn how to recreate the problem. The only thing I could have done was to send him my whole application, which is about 7 meg zipped without any data files, or spend a few hours trying to trim it down and still keep it working. The app is complex and tightly integrated so I wasn't willling to spend the time.

              This may not be much help but at least I can say that I've never had a problem when the refresh ran all the way through correctly.

              I made some changes that have improved the situation. Unfortunately, I don't know what changes made the improvement. At least I don't get any shadow .adb files on the server any more. However, I'm still having issues with some refreshes on that app when run from a button on my Utilities Menu. The automated refresh that runs when the server version is updated now runs perfectly every time and that's good enough until I have time to work on the other issue.

              Cal Locklin
              www.aimsdc.net

              Comment


                #8
                RE: shadow copy, client overwrote server

                Thank for the insight, that's exactly what's happening. Hopefully its something that will work itself out. I might have to pursue a similar work around. I wish I didn't have to rely upon the users to monitor this problem. If the process is a "pull", I don't understand how the server can be overwritten. Weird.

                Comment

                Working...
                X