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

Problem with multiple deletes

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

    Problem with multiple deletes

    I am looking for a way to check if the deletion process is complete when a number of records in a child browse in a set are highlighted and deleted. When the records are all deleted, I need to pack the child table and clean up indexes. I have a set that must use filtered indexes (I wish I had a better way, but) and I get the dreaded Heap Lock Failure after I delete a number of records. Deleting one record at a time is no problem as I can attach a script to the OnDelete event in field rules, but multiple deletes fire the OnDelete event on each delete and the program crashes.
    Anyone with a workaround?

    Jerry

    #2
    RE: Problem with multiple deletes

    Jerry,

    I think there is a command .delete_range() at the table level. I have used it and it works well! You might check it out.

    Daryl

    Comment


      #3
      RE: Problem with multiple deletes

      Jerry,

      That's a good suggestion Daryl made but note that delete_range will not trigger your on-delete code which can be a good thing or a bad thing depending on circumstances.

      I have never had any hangups or issues with the command.

      I discovered this while preparing the little article on querying child records which was recently posted at learn alpha.com. It's a side issue but I discuss it a bit in the article.

      Bill
      Bill Hanigsberg

      Comment


        #4
        RE: Problem with multiple deletes

        Where our accountant has to delete records from a report we use a form with an embedded browse. She then marks ([Ctrl][M]) each record/row as needed. After marking all applicable records a button is clicked which runs a global script to delete marked records. Selection criteria used is

        marked("FileNameWithoutExtension")

        After this she clicks a button which performs a pack operation. Xbasic, but don't remember it off hand. Something like

        TblPtr.pack(.T.)

        As far as I know, we haven't had heap locks using this method. If you use an index with a filter checking for marked records you might. I've noticed when deleting ([Ctrl][D]) a number of records a heap lock can be generated which, if the table's indexes aren't rebuilt, can result in index corruption forcing you to rebuild them. The method above has not, to my knowledge, resulted in any problems.

        Comment


          #5
          RE: Problem with multiple deletes

          Lots of good suggestions. The problem with delete_range() is that I want to only delete child records that are selected by the user from an embedded browse. As far as marking the records, I tried that method also, but for some reason this doesn't work in my set for child records. [CTRL-M]has no effect on the records. The set I use has the same child table linked four times to the same parent with different filtered indexes. This obviously also causes some problems when records are saved, but I have a workaround for that.

          If I eliminate the OnDelete field rules, I can highlight multiple records and delete them, but then the remaining records don't link correctly until the indexes are reindexed. I may have to resort to adding a button to manually pack the tables, but I was hoping to automate the process to make it more transparent.

          Thanks for the ideas.

          Jerry

          Comment


            #6
            RE: Problem with multiple deletes

            If you have a script that deletes the records after they have been selected, then the script will work without the Heap Lock error if you can issue a
            batch_begin() and batch_end() around the code that does the deletes. The success of the batch_begin() and batch_end() requires exclusive access to the table.

            Comment


              #7
              RE: Problem with multiple deletes

              Peter,

              Thanks for the idea about batch_begin() and batch_end(). I had forgotten about their use. I think my initial post was somewhat unclear about my problem. I was looking for a way to determine when the deletion process was complete for all of the highlighted records in a child browse. The reason I wanted to do this was to run a script to automatically pack the tables when the deletion was complete. Since the original post, I have come up with a workaround that might be of use for others. I have posted the solution and explanation below.

              I initially came up with a solution which worked if only one child record was deleted. Since pack() requires exclusive use of a table, I had to close the original form, run .pack(), and then reopen the form to the original parent record. I attached a script to the OnDelete field rule for the child table. I have a table in my database with only one dummy record. I use this table for various menu forms and dialog forms. The OnDelete script would open a form in the dummy table that looks just like the form for the set with all fields removed and replaced with a message "Please Wait - Creating File Data". When this form would open, it's OnActivate event would close the original form. When the original form closed, its record number was saved in a global variable. Then I used an OnTimer event on the dummy form to run the .pack() for both the sets parent and child tables. When the pack was done, the OnTimer script would reopen the original form and use the global variable to find the original record. The original form would then close the dummy form. This was fine for only one deletion, but would lock the program if multiple lines were selected for deletion.

              After some testing, I isolated one problem to the main form closing before all lines were deleted. I wanted to wait to fire the OnDelete event until all records were deleted. A second problem was that the OnDelete event was trying to activate the dummy form on each delete. The solution to the first problem was simple. If I couldn't determine when all child records were deleted, I simply need to wait an appropriate amount of time to close the main form. Since the main form was being closed by my dummy form, I moved the form.close() lines to the OnTimer event. I set the timer interval to an appropriate time - about 3 sec - and now there is plenty of time for all deletions before the form closes. The second problem was also simple. I used is_object to check if the dummy form was open. If it was, the OnDelete event would end. If not, it uses form.view() to open the dummy form. I found that these solutions work even if the dummy form is loaded with form.load() and never activated. The user never knows what is happening in the background.

              I can post the code to each event if anyone wants it. Opening a dummy form and using OnTimer is one way to close a form, work with the tables in exclusive mode, and then reopen the original form with no intervention from the user.

              Jerry

              Comment

              Working...
              X