With this simple schema in SQLServer:

CREATE TABLE [dbo].[titles] (
    [titleid] INT           NOT NULL,
    [title]   NVARCHAR (50) NULL,
    PRIMARY KEY CLUSTERED ([titleid] ASC)
);

GO

CREATE TABLE [dbo].[divs] (
    [divid]   INT           NOT NULL,
    [titleid] INT           NOT NULL,
    [name]    NVARCHAR (50) NULL,
    PRIMARY KEY CLUSTERED ([divid] ASC),
    CONSTRAINT [FK_divs_titleid] FOREIGN KEY ([titleid])
		REFERENCES [dbo].[titles] ([titleid]) ON DELETE CASCADE
);

GO

CREATE TABLE [dbo].[articles] (
    [articleid] INT           NOT NULL,
    [titleid]   INT           NOT NULL,
    [name]      NVARCHAR (50) NULL,
    PRIMARY KEY CLUSTERED ([articleid] ASC),
    CONSTRAINT [FK_articles_titleid] FOREIGN KEY ([titleid])
		REFERENCES [dbo].[titles] ([titleid]) ON DELETE CASCADE
);

GO

CREATE TABLE [dbo].[books] (
    [bookid]  INT           NOT NULL,
    [divid]   INT,
    [titleid] INT           NOT NULL,
    [name]    NVARCHAR (50) NULL,
    PRIMARY KEY CLUSTERED ([bookid] ASC),
    CONSTRAINT [FK_books_titleid] FOREIGN KEY ([titleid])
		REFERENCES [dbo].[titles] ([titleid]) ON DELETE CASCADE, 
    CONSTRAINT [FK_books_divid] FOREIGN KEY ([divid])
		REFERENCES [divs]([divid]) ON DELETE NO ACTION
);

If one changes the last ON DELETE clause to ON DELETE CASCADE, you get the dreaded

"Introducing FOREIGN KEY constraint may cause cycles or multiple cascade paths"

error.

I've never run into that with SQLite. With the equivalent schema

BEGIN TRANSACTION;
CREATE TABLE IF NOT EXISTS "titles" (
	"titleid"	INTEGER,
	"title"	TEXT,
	PRIMARY KEY("titleid")
);
CREATE TABLE IF NOT EXISTS "articles" (
	"articleid"	INTEGER,
	"titleid"	INTEGER NOT NULL,
	"name"	TEXT,
	PRIMARY KEY("articleid"),
	FOREIGN KEY("titleid") REFERENCES "titles"("titleid") ON DELETE CASCADE
);
CREATE TABLE IF NOT EXISTS "divs" (
	"divid"	INTEGER,
	"titleid"	INTEGER NOT NULL,
	"name"	TEXT,
	PRIMARY KEY("divid"),
	FOREIGN KEY("titleid") REFERENCES "titles"("titleid") ON DELETE CASCADE
);
CREATE TABLE IF NOT EXISTS "books" (
	"bookid"	INTEGER,
	"titleid"	INTEGER NOT NULL,
	"divid"	INTEGER,
	"name"	TEXT,
	PRIMARY KEY("bookid"),
	FOREIGN KEY("titleid") REFERENCES "titles"("titleid") ON DELETE CASCADE,
	FOREIGN KEY("divid") REFERENCES "divs"("divid") ON DELETE CASCADE
);
COMMIT;

cascades from deletion work as advertised.

With SQLServer, the workaround for cascade conflicts is triggers, and I remember having to use triggers for cascades in SQLite because foreign keys weren't enforced. If I remember correctly, when enforcement was implemented, it was done internally with trigger programs anyway.

It occurred to me that I've never run into a cascade conflict with SQLite. Is that because cascade conflicts aren't a problem in SQLite? And if that's the case, is that documented? I couldn't find anything about it in the docs.

Somehow, it seemed clearer when cascades had to be done with triggers (I hate it when things happen that I can't see).