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

tbl.packed being interrupted!

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

    tbl.packed being interrupted!

    I have a main database that contains a dbf called "New_Location" and runs a main script every 15 minutes. "New_Location" has records appended to it by another form (via the network at workstations) called PCScanner. For some reason, after a station has sent data to "New_Location" it causes the main database to stop running the main script with an error message stating that "tbl.pack() table in use by another user." The only way I have been able to get around this problem is by turning off the computer with the problem and then rebooting it.

    This same problem does occur the opposite way also. If the main database happens to be in the middle of the main script and a workstation attempts to append records, the workstation receives the same error. So, what is going on here? Do I need to have a "FILE_RW_SHARED" put somewhere in the script on both pieces of software to let the appends and main script work without interrupting each other? If necessary, I can forward the script or database to anyone willing to look at it. Thank you.




    NATHAN

    #2
    RE: tbl.packed being interrupted!

    Hello Nathan,

    >>and runs a main script every 15 minutes.

    Comment


      #3
      RE: tbl.packed being interrupted!

      Jim:
      This morning I ran a test where two workstation computers sent info to the main database. Both computer's software ran properly and the appends had no problems appending to the same main database at the same time. However, after the fact of all software being ran, and closed, the main database still thinks that another user is using the file and refuses to pack the database. I'm thinking that the append operations from the other computers are telling the main database that they are still accessing the .dbf that the main database is trying pack. (I could be wrong) Is there some way to reset the main database to think that no other users are accessing it? Or, should I have an inline script follow the append operations which attempts to close the main database .dbf? I'm not sure what is going on.



      NATHAN

      Comment


        #4
        RE: tbl.packed being interrupted!

        Hello Nathan,

        >>However, after the fact of all software being ran, and closed, the main database still thinks that another user is using the file and refuses to pack the database. I'm thinking that the append operations from the other computers are telling the main database that they are still accessing the .dbf...

        Comment


          #5
          RE: tbl.packed being interrupted!

          JIM:

          "When you say 'refuses to pack' are you trying to run your routine and it is failing or are you right clicking on the table and selecting 'Pack' from the menu?"

          I'm using a script to pack the table. The following is the script which is used. An error messages occurs when the first pack command is executed.

          'copy table New_Location to New_Location2
          filenameTemp = ("C:Program FilesA5v4trackerNew_Location.dbf")
          filenamePerm = ("C:Program FilesA5v4trackerNew_Location2.dbf")
          File.copy(filenameTemp,filenamePerm)

          '***Clear New_Location.dbf table*********************
          ModeCheck01:

          tbl=table.open("C:Program FilesA5v4trackerNew_Location.dbf",FILE_RW_EXCLUSIVE)
          IF tbl.mode_get() = 0
          tbl.zap(.T.)
          tbl.pack()
          tbl.close()
          ELSE
          GOTO ModeCheck01
          END IF

          '****************************************************
          :Import.run_silent("Import New Locations")
          :Append.run_silent("Append New Locations")
          script_play("Append_New2Last")
          script_play("Copy Location Database")
          script_play("Delete New Locations Fil")

          '***Clear New_Location2.dbf table*********************
          ModeCheck02:

          tbl_2=table.open("C:Program FilesA5v4trackerNew_Location2.dbf",FILE_RW_EXCLUSIVE)
          IF tbl_2.mode_get() = 0
          tbl_2.zap(.T.)
          tbl_2.pack()
          tbl_2.close()
          ELSE
          GOTO ModeCheck02
          END IF

          '****************************************************
          :A5.close()

          "New_Location.dbf" is a file that is updated via an append function from other workstations over the network (its pointer is tbl). New_Location.dbf is a table in the main database which is used to transfer in new records. It acts as a holding tank. When the main computer attempts to pack tbl, an error message occurs stating that there is another user using the table. This seems to occur because of other computers on the network, who access "New_Location.dbf", who run WIN95/98 and/or have slow processors (400-600MHz). I would think these systems would be fast enough, because there isn't any script too complicated. Another problem with these computers occurs usually right after A5 is closed. It seems to have a conflict with windows Explorer (NOT internet explorer) and the computer forces 'illegal operation' errors to occur. The details indicate "Alpha5 caused an invalid page fault in Alpha5.exe..." and "Alpha5
          caused an invalid page fault in module MFC40.dll...". I have no idea if these things are related, however, my other computers which run on WIN2000 have no problems.

          "The built in append operations should be releasing the table after they are run. Are you using the built in append operations or are you manually coding them?"

          The append is a built in append function which I created under the operations tab. I used the wizard to construct the specifics of the append. This append is part of the workstation program. The append operation updates the "New_Location.dbf" at the main database.

          I apologize for the lengthy reply, however, I'm trying to give you the clearest picture of what is happening. Thanks for your time and effort Jim.



          NATHAN

          Comment


            #6
            RE: tbl.packed being interrupted!

            Hi Nathan,

            I'll look at your script later tonight when I have more time, but one thing jumps out at me, you are running a pack() right after a zap(). This is unnecessary as zap() does it all in. There is nothing left to pack(). This may be the issue, but I don't know as I've never tried it.

            Jim

            Comment


              #7
              RE: tbl.packed being interrupted!

              Hello Nathan,

              I tried the pack after a zap and there seems to be no problem doing this, so I don't think this is related to your problem.

              Is this a network optimized setup? If so it was just reported that table.open("tablename", file_rw_exclusive) on a shadowed database does not return an error if exclusive use is not granted. This sounds like what you've got going on. Try this by logging in to the real database on the server rather than the shadowed database and see if this error goes away. Search the message board as I remember reading this not very long ago.

              Good luck,
              Jim

              Comment


                #8
                RE: tbl.packed being interrupted!

                Nathan,

                Here's the message I read>>

                Msg ID: 41307
                Subject: RE: A5 Constants sometimes not found
                Author: John Zaleski
                Date: 05-13-2001 22:18
                File:

                AS a followup to my part of this thread, Peter Wayne confirmed the file lock problem in an optimized database.It happens in v4.03 v4.5 and v5 beta. He reported it to Selwyn. To reproduce the problem:

                1)Open an optimized database
                2)open a form or a browse for any table and minimize it.
                3)In the interactive window type:
                t=table.open(tablename,file_rw_exclusive)

                You should get an error here and you will in a non optimized database. However in an optimized database you do not get an error. I mention this in case others have scripts that depend on this working in optimized situations.

                John

                Comment


                  #9
                  RE: tbl.packed being interrupted!

                  Two additional comments about Nathan's problem. I have found that combining operations in xbasic can at times be problematic. I have found that if you explicitly close the table at the end of the operation, and then reopen it for the next operation, everything works ok. However, if you attemp to run another operation without the close and open, sometimes A5 will generate an error. The second issue is that it is a good idea to try to trap any error that occurs if use FILE_RW_EXCLUSIVE. Otherwise, the program can lock. Below is a example of a part of a script I use to pack() tables. I am getting the table name from an array

                  on error goto error_msg

                  no_error = .T.
                  for i = 1 to count
                  tbl = table.open(tables(i),FILE_RW_EXCLUSIVE)'//// Only pack if file is open exclusively
                  if no_error
                  tbl.pack()
                  tbl.close()
                  end if
                  no_error = .T.
                  next

                  END

                  This will trap the open error and show the user what is happening.

                  Jerry
                  error_msg:
                  ui_msg_box("Remove Deleted Records","Deleted records could NOT be removed "
                  +chr(13)+"from "+tables(i)+" file.",UI_INFORMATION_SYMBOL)
                  no_error = .F.
                  resume next
                  end

                  Comment


                    #10
                    RE: tbl.packed being interrupted!

                    I'm curious if you have considered some of the errors I mentioned in the previous reply? I understand what is being suggested to do, however, I only have problems with this software on WIN95/98 machines and/or have smaller processors. Why is that? Some of my WIN98 and all of my WIN2000Professional work just fine. Would optimization be a necessary step, considering the different responses I get from the different operating systems?



                    NATHAN

                    Comment


                      #11
                      RE: tbl.packed being interrupted!

                      Nathan,
                      There may be some code missing from your script, but as I read your code:
                      ModeCheck01:

                      tbl=table.open("C:Program FilesA5v4trackerNew_Location.dbf",FILE_RW_EXCLUSIVE)
                      IF tbl.mode_get() = 0
                      tbl.zap(.T.)
                      tbl.pack()
                      tbl.close()
                      ELSE
                      GOTO ModeCheck01
                      END IF

                      if the tbl.mode_get fails, then you return to run the routine again, BUT, you have already open the table in exclusive mode, so A5 won't let you open it again. you need to add a "tbl.close()" command after the ELSE command.
                      Pat Bremkamp
                      MindKicks Consulting

                      Comment


                        #12
                        RE: tbl.packed being interrupted!

                        Hi Pat,

                        Sharp eyes there Pat, the 'ModeCheck01:' label should be after the table.open() command.

                        Again, if I read the post I copied into this thread correctly, then on a network optimized database, opening a table in exclusive mode does not give an error if exclusive mode is not granted. This would cause a pack to fail if someone else was in the table. I would hope that the different OS's don't have anything to do with this problem. My guess is that it's governed by who's most likely in the table when this routine is run. For instance, you have a win98 and a win2000 sytem. Maybe the most intensive data entry is coming from the win98 machine. Running the routine on the win2000 system fails because the win98 system is in the table. Running the routine from the win98 system works as the win2000 is normally not using the table. It is my guess (and hope) that it is this type of an issue, not an OS issue.

                        Good luck,

                        Jim

                        Comment


                          #13
                          RE: tbl.packed being interrupted!

                          Jim,

                          I have not yet moved to V4.5, but a little experiment has shown another possible file lock problem that is present even in V4 build 230. I opened a table using xbasic and then tried to open the same table in another script in exclusive mode. A5v4 allowed the second script to open the table. It did not show the table as already open. This occured even if the first script not only opened the table, but also started a change operation. Interestingly, a pack operation proceeded apparently correctly from the second script. This was on a standalone database, not a network optimized version.

                          Jerry

                          Comment

                          Working...
                          X