…again…you need to take responsibility for entering things correctly. You have chosen to blindly import from FamilySearch instead of manual entry where you can make sure things are correct. Again I will state, mass deletions of places is something I wouldn’t expect to see any time in the near future. People already find enough ways to screw up their data, giving them another way is not a good idea.
1 Like
Bulk deletion of unused Places is easily handled with a SQLite query. There are no adverse consequences, unlike the usual tip to drag’n’drop everyone to a new database which does have undesirable collateral effects. It has always mystified me that RM development has never added such an easy-to-add and harmless feature.
https://sqlitetoolsforrootsmagic.com/places-delete-unused/
Harmless my ass! If you insist on flogging methods that are more than likely going to give way too many people a chance to hork their database, then how about you do something to make it easier. Fire up your favorite development environment and churn out an app that will backup the users database, then allow them to apply all of those spiffy SQL scripts that you are so fascinated with.
Otherwise about 97.32692% of the RM userbase shouldn’t even know there is a tool that will let them frack things up in short order. SQL is NOT an acceptable tool for the masses. So in other words, put up or shutup!
Tripled support would likely be the result. Three types of folks would attempt the feature:
- The fewest would be those that really understand what they’re doing.
- A slightly larger group who would have varying levels of success on their own or at the behest of other suggestors.
- The most who shouldn’t be allowed anywhere near such a facility as they already have difficulties in the program’s current configuration. Just saying. Backups are too often an afterthought.
What harm do you envision from RM developers adding a feature to bulk delete unused Places?
RM Support typically recommends that people wishing to clean out unused Places, Sources et al can do so through a GEDCOM Export-Import or Drag’n’Drop to a new database. Now that is potentially harmful, partly because of the risk of user error but also because it’s not quite transparent to all data, even that which is ‘used’.
I did so around a decade ago and ‘churn’ might be an apt description of the process because, unlike you, I am not a software developer and struggled to get the thing going. Some people still use it…
https://sqlitetoolsforrootsmagic.com/bundled-utilities-rmtrix/
If you would like to bring your skills to the table to update it for RM8, add more features, make it MacOS compatible, that would be amazing!
I don’t follow. Any new feature is liable to have concomitant support impact; some more than others. Reuse of citations and, especially, the ‘Merge all duplicate citations’ in RM8 definitely on the ‘more’ side and potentially very harmful. ‘Delete unused places’ would have little negative effect on support while eliminating the recurring complaints about how laborious it is.
I am aware of your previous release and have even used it a few times. If you think about it, if @karlief had known what he was doing and merged his places as he could have done, then he wouldn’t have had a boat load of unused places. You get unused places from manually changing the place on the edit screen. Merging does just that, no left overs. In this case, SQL wasn’t needed to do bad stuff. Image if he had that power…
As for developing anything, first, you might have missed the ‘recovering’ reference when I mentioned software development in a recent post. Second, no way in Hades am I paying Apple for the privilege of developing for the Mac eco system. Third, I am two lazy to stumble though the database diagram and write queries.
SQL is a beast all its own, people that do not know better should not be directed to use it to fix their problems, unless you are going to personally unhork their databases for them…because you know they wont have a backup!