[Solved] Editing Multiple Records

Hi Joe,

Can I assume that you are running v6.0.x?

I assume this has only happened once for you, as I have never seen this before and it has not been reported before.

How many records (approx) are you attempting to edit at once? 10, 100, 1000, etc?

If it doesn't respond after waiting for a couple moments, something is going on with your system, hardware, etc. Could be antivirus program (scan), hardware overheating, virus causing file corruption, etc.

Stop BD by clicking the "X" in the upper right of the main window. If that doesn't work, stop it by using the Task Manager (Ctrl+Shft+ESC).

Consider rebooting your computer at this point.

Before restarting BD, make a copy of your database C:\Birder's Diary\data\database.mdb. For safety's sake.

Now restart BD and attempt the same operation.

Let's start here.

Please let me know. 

Update: Joe responded via email with the solution.

It was notifying him of Lifer changes after the changes he made with the edit. This notification, by default, blocks awaiting for the user to respond. You can acknowledge the notification and/or change the settings so that it no longer blocks execution after the notification. 

fyi.

Update: We have determined that this was not the problem. Joe acknowledged the notification, but the edit still hung.

Going to get onto his computer and check this out this coming week.

Got onto JC's computer today and verified the issue. Got a copy of his DB onto my development machine and was able to reproduce the issue.

JC has 591k sightings in his DB. The lifer counts seem to bog down and the performance varies wildly from one execution to the next, simply due to the  large number of sightings here. Calculating the same count can vary from 1s to 20s each time it is calculated (e.g. Lifers for ABA Area using Clements 2022).

I have to date, spent 5 hours testing and debugging this in an attempt to improve this performance. I have gained little if any ground. 

I was able to reproduce this by randomly producing 600k sightings in my test database and I got the same slow performance in calculating lifer counts.

This same code is repeated when entering sightings or editing a sighting, in order to determine if the sighting is now a World/Location/Annual/Recent Lifer. This is what JC is experiencing when he edits multiple sightings now. It doesn't hang forever, and eventually completes.

This same code also affects rebuilding the Lifer Bars on the main window background.

Some Solutions

• On View | Options -- Petey-Lifers TAB, uncheck the Celebrate Lifers checkbox, to disable this check when entering or editing sightings. CORRECTION: see posts below. This option is no longer needed. See the Reply below about disabling Auto-Calculation.
  

  

• The Sightings View/Edit window can also be slower due to this Lifer Check code. In order to speed that up, uncheck the Lifer checkbox on the Options pane.
  

  

Still digging into attempts to improve this issue, but I wanted to get this out now. Stay tuned here.

The one thing that JC mentioned is that this just started happening when editing sightings. Hmmmm. Did you just upgrade to v6.0 recently?

This code was added to v6.0 to check for Lifers when editing. That causes updates to Lifer Bars, Lifer Counts in the status bar, etc. That is the slow down.

Working on correcting and improving this.

You would have gotten this same slowness every time you added a new sightings, upon closing the Sightings Entry window.

Interesting that you reported this only on the Edit function. 

It would have also happened at the end of each Sightings Import, if you used that.

Also, if you deleted records from Sightings View/Edit.

These would have been around for a long time.

The net result is, I did not test the performance of this code against 500k+ sightings.

The problem is NOT checking to see if your edited or new sightings are Lifers, but in recomputing your Lifer totals and Lifer Bars.

The solution now, is that instead of turning off Lifer Celebrations, as shown above, and as you have done, instead you should disable Auto-calc of these counts, as shown below.

The 3 Lifer Counts in the Status Bar at the bottom left will still auto-calc on BD startup, but not the lifer bars. You can disable this by removing those Locations when you edit your observer.

After much analysis and testing, if you have a DB with over 200k sightings you might be affected by slow calculations of Lifer Bars, 3 Status Bar Lifer Counts, and Lifer Celebrations. It depends on the number of sightings, size of database, amount of memory on your computer, complexity of locations (# of descendants) that are being calculated, and probably a couple more things.

I plan to implement code that tests for this slowness and give the user the option to turn stop the calculations.

In the meantime, doing these three things will turn these features off.

1. In View | Options, General 1 Tab, Check the "Disable Auto-calculating Life Counts after Data Entry" option.
2. In View | Options, Petey - Lifers Tab, uncheck "Celebrate Lifers"
3. In the Observer Maintenance window for the Current Observer, clear the Location fields for the three Lifer Count options.

This will eliminate this functionality from occurring going forward.

fyi

In addition, the DB queries for this functionality simply don't perform well under the above mentioned circumstances. I am looking for ways to perform this functionality better, but have not currently found it.