There are two facets to this:
1. Someone has introduced a ParentID into the Page object. Not sure how (decorator?) but when you upgrade to 2.4.2 from 2.4.0 and do the dev/build you can see it being created (Page.ParentID & Page_live.ParentID).
2. As I have now learnt to my own joy developers are advised to ALWAYS qualify your database table references.
I even myself had previously assumed (yes, Ass, You, Me) that as SiteTree was the basis for all Pages (Page being an extension of SiteTree) there would be no need for another ParentID in child objects and have never bothered to fully qualify it as I have done for nearly all other fields where they may appear in another object and get picked up in the DataObject::get's huge database join.
E.g. while I would have gone
$theThingies = DataObject::get('Thingie','"Thingie"."ID" = 0');
$theThingies = DataObject::get('Thingie','ParentID = 0');
$thePages = DataObject::get('SiteTree','"ParentID" = 0');
Where the first will always be valid and has to be done as you could never be sure there wasn't another object with field name ID, but the next two I always considered okay (as covered in my assumptions above). So I have had to whip through all my code and change occurrences like the 2nd & 3rd to
$theThingies = DataObject::get('Thingie','"SiteTree"."ParentID" = 0');
$thePages = DataObject::get('SiteTree','"SiteTree"."ParentID" = 0');
So go through any of your own code and check you always qualify your dB search strings. And use the double quotes ("Page"."Afield") so that the data query engine will properly automagic that into Page or Page_live as appropriate.
And, yes, if you like to use double quotes to start strings and delimit inside with single quotes that also means going through all that code and reversing the usage. E.g. "ParentID = ".$this->ID now has to be '"SiteTree"."ParentID"'.$this->ID. So the string is now delimited by ' so you can use " to wrap the table and field names. Of course you can always be a step better than me and stick to always double quotes but escape embedded ones.
Silverstripe people - was there a reason for this new field? And where does it come from? I've done a quick scan of code but cannot locate it. Fair enough that we should code to avoid ambiguity but why was a ParentID field needed in page the first place? Unless there is an intent to step above or abandon SiteTree? Not following development news I have no idea so feel free to tell me where to get off (O:
Pter