The file is the one currently being written to. When you copy it, that's no longer the case.

Triggers on the tables beneath the views, with logic to determine whether the changes that fired the trigger would affect the views or not.

Triggers on the tables that make up the view (trigger on the view doesn't fire unless the view itself is the target of the modification)

Check that the app is connecting to the listener, not to the server directly.

If...

Keep in mind sequences can and will have gaps in them. This is not a bug.

sys.dm_exec_query_stats is dependent on the query's plan being in cache. When the query's plan is removed from cache, the query stats for that query are removed.
Hence, what you're seeing...

As I said, you're going to need to redo it. i.e. full database restore

But, before you do that, it may be a good idea to recover the DB...

You'll have to code that manually as you do the insert, stored procedure for insert would probably be best.
Do watch out for concurrency errors, this kind of  thing is...

Looks like the transaction log on the secondary is damaged (or could be the data files)
You're going to need to re-do it, and it may be a good idea...

Are you talking about constructing 'lookup' tables in a query?

Like
SELECT <stuff> FROM  Transactions
Inner Join (SELECT 1 As StatusID, 'Active' as Status UNION ALL...