I noticed in the paper this weekend that the property known as “The Grange”, in Queens Rd New Lambton, is up for sale. This house and surrounding area was originally owned by William Thomas Dent, who was Secretary of the Northumberland Permanent Building Investment Land and Loan Society for 43 years.
“The Grange”, New Lambton
The building and land was sold by Dent in October 1921, purchased by the Newcastle Hospital Board for £4387. They planned to convert the property into a convalescent home.
“The Grange” in New Lambton in 1921, purchased for use as a convalescent home.
The planned conversion of “The Grange” to a convalescent home never happened, as the following year the hospital board purchased Lambton Lodge (the former home of Thomas Croudace, manager of Lambton Colliery) and developed it as the convalescent home instead. With “The Grange” property now surplus to requirements, the hospital board subdivided the land, and in June 1930 offered for sale 25 blocks of land around the original house.
The Grange Subdivision 1923.
W T Dent moved to a house in Curzon St New Lambton, where he died in 1942.
W T Dent properties in Curzon/Curson St New Lambton.
The other William Thomas Dents
The William Thomas Dent (1870-1942) who owned The Grange is not to be confused with his father, also called William Thomas Dent (1844-1901) who was secretary of the building society before his son, during the years 1877 to 1899. William Thomas Dent senior was the fifth Mayor of the Lambton Municipality and was instrumental in the erection of the Lambton Park Rotunda, and has his name in the ornamental ironwork above the entrance.
“W T Dent Mayor” on the Lambton Park rotunda.
Additionally note that the William Thomas Dent (1870-1942) who owned “The Grange” also had a son called William Thomas Dent (1901-1930) who predeceased his father, aged just 29.
[Note that the birth year I have stated for the three W T Dent’s above are approximate only, based on their age reported at their death.]
This week at work I struggled with a Salesforce Flow that I was trying to delete, but couldn’t. It seemed to be a bit of a ‘zombie’ Flow, that was a little bit alive and a little bit dead. It all made sense in the end, but when I was in the middle of it all, it seemed inexplicable.
It started with a custom field that our company had added some time ago, which was no longer needed and I wanted to delete. On trying to delete the system wouldn’t let me, saying that it was in use by a Flow. I clicked on the “Where is this used?” button which identified that the field was referenced in a flow.
Clicking on the hyper link to the Flow, opened it in the Flow Builder, but that interface does not allow any way for the the Flow to be deleted.
So I went to the Setup interface, to the Flows menu item to delete it. But although the Flow clearly existed (I had it open in Flow Builder a moment ago) it wasn’t appearing in the “All Flows” list for me to delete.
Next, I thought I’d try to delete this zombie flow by using a metadata deployment. I use the Gearset tool for deployments, and by comparing a sandbox Org without the Flow to the one that had the Flow I generated a ‘delete’ type deployment … which then failed with the unhelpful error message “Insufficient access rights on cross-reference id”.
Eventually I figured out that the Flow couldn’t be deleted because it was referenced from a Process Builder. When I had located and deleted that Process Builder the ‘zombie’ Flow disappeared, and I was then able to delete the custom field. What made things tricky was that it wasn’t the latest active version of the Process Builder that referenced the Flow, but an earlier inactive version, so I had to search through all the earlier versions to identify the one that needed to be deleted.
The bottom line is that Salesforce won’t let you delete something that is referenced by some other design element. That’s a good thing. But the bad thing is that it can sometimes be hard (and non-obvious) finding what exactly is referencing the element you’re trying to delete.
I get some amusement by pondering that somewhere in the world, there is someone whose job is to come up with names for new prescription drugs. Of course there a few basic rules in naming a new drug …
it must be memorable
it must be easily pronounced
it must be sufficiently distinct from existing names
it cannot spell or sound like a rude word in any of the hundreds of languages in the world.
But the most important rule of all is …
the name must be able to be credibly used in the title of a Doctor Who episode.
To illustrate my point, click on the button below to show an actual Doctor Who episode title, with one word substituted for an actual prescription medication sold in Australia. Doctor Who fans can try to guess the real title.
This post is mostly a reminder to myself for the next time I need to do this …
For backing up files on my laptop running Window 10, I have an external USB hard drive permanently plugged in to my docking station at work. I then have backup software that runs backup jobs at scheduled times during the week. Recently I needed to upgrade to a larger capacity hard drive. With the purchase of a new hard drive, I also decided it was an opportune time to start using Microsoft’s BitLocker to encrypt the backed up files.
After plugging in the new drive and setting up BitLocker, I found that the backup performance was woeful. Backup jobs that used to take a few minutes were now taking hours. After a bit of experimentation and research, I found that the performance issue was nothing to do with BitLocker, but simply that I needed to disable write caching on the external drive.
The steps to achieve this were:
Open Windows Device Manager.
Locate the external drive in the list, right click and choose Properties.
Click on the Policies tab.
Change from the “Quick removal (default)” setting to the “Better performance” setting.
After doing this, backup jobs now ran in the same small amount of time as when I used the previous drive.
Despite the fact that I specifically wrote myself a blog article as a reminder to myself to never turn on iCloud music syncing on my phone, Apple tricked me with the latest iOS update. After updating to iOS 13 the music app displayed a warning that “Library Syncing is Off. Turn On”. In my haste to dismiss the message I tapped “Turn On”, then moments later realised that this was the dreaded iCloud sync under a different name. I quickly turned if off again, but not before the sync had removed the star ratings I had applied to hundreds of my tracks. 🙁
Dear Apple, you may have removed the name “iCloud” from the sync, but it’s still crap.