Skip to main content

3M To Pay Over $7 Billion To Settle 'Forever Chemical' Groundwater Claims

1 day 7 hours ago
3M has agreed to pay up to $7.35 billion over nine years to settle claims from as many as 120,000 people who say they were sickened by PFAS-contaminated groundwater near military bases, airports and other locations where firefighting foam was used. The Associated Press reports that 3M "did not admit liability," noting that the settlement comes on top of the more than $10 billion the company previously agreed to pay U.S. public drinking water systems over PFAS contamination. From the report: 3M chairman William Brown called the settlement a "significant milestone" that substantially reduces uncertainty from the litigation. [...] Fred Thompson, an attorney with the Motley Rice law firm that helped negotiate the 3M settlement for the plaintiffs, called it welcome news for "the thousands of victims who have sought answers and accountability for nearly a decade." He said in a news release that the plaintiffs urgently need help covering mounting medical bills and other costs. Under the terms of the settlement, the payouts will begin with $50 million this year, followed by yearly payments of more than $1 billion each year from 2028 to 2033. 3M could make additional payments if enough plaintiffs participate. If too few sign on, 3M has the option to cancel the settlement and continue fighting the lawsuit.

Read more of this story at Slashdot.

BeauHD

CodeSOD: Only Create Me if I Exist

1 day 8 hours ago

Foreign keys are an important part of making sure the entities in our relational database can be connected back together and queried correctly. It's part of proper data normalization. This isn't shocking, of course: the order line table has a foreign key over to the products table, so that every line item points to a product we sell. That's database 101. Database 201, you'd also think about the times where you have a hierarchy of records, where say, every Employee has a ManagerId, which is a foreign key back to the Employee table itself (and in database 301, you'll understand why having a ManagerId field is a terrible choice, but that's neither here nor there).

The important thing here is that foreign keys are very common, and foreign keys pointing back to the same table are also very common.

But it can still go very wrong. Roman sends us this foreign key definition in a database they maintain.

ALTER TABLE [dbo].[ListingDetails] WITH CHECK ADD CONSTRAINT [FK_Listings_Listings] FOREIGN KEY([Id]) REFERENCES [dbo].[ListingDetails] ([Id])

This ensures that the ListingDetails table's Id field is a foreign key over to the ListingDetails table's Id field. A field is a foreign key back to itself.

Roman writes: "I can't believe SQL Server even allows this..."

I can. While I haven't personally tried this out, a bit of cursory searching implies that this does actually work- the record satisfies its own constraint, so you can still add it to the database. It's basically a no-op, which isn't great, but it's not SQL Server's job to ensure you keep all your toes because they've removed all the footguns.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!
Remy Porter