I'm using Microsoft's SqlDataConnection type provider. However, the only way I've seen to update a row in the database is to use something similar to this where it updates mutable values:
let updateProduct product =
let currentProduct = query {
for c in context.Product do
where (c.Pro...
So a user can have many subscriptions, and a subscription belongs to one plan. The plan table tells us a subscription's cost. Is the query below the correct one for figuring out the number of subscriptions purchased by a user with an "ongoing" status and the total revenue brought in each day b...
So, I've given up on the issue I've spent hours researching since yesterday.
It bugs me that we have thorough audit triggers and tables for some of the most trivial production tables, but for mission-critical things we just delete rows and they are just gone without a trace.
Nitpicks
You use separate statements for DECLARE and SET quite a bit. While there is nothing wrong with that, it's often just easier to read if you combine them:
DECLARE @Xdaysago datetime = DATEADD(DAY, -(@historyDays), GETDATE());
DECLARE @chunkCount int = 0;
DECLARE @procRunDate datetime = G...
So a user can have many subscriptions, and a subscription belongs to one plan. The plan table tells us a subscription's cost. Is the query below the correct one for figuring out the number of subscriptions purchased by a user with an "ongoing" status and the total revenue brought in each day b...
Nitpicks
You use separate statements for DECLARE and SET quite a bit. While there is nothing wrong with that, it's often just easier to read if you combine them:
DECLARE @Xdaysago datetime = DATEADD(DAY, -(@historyDays), GETDATE());
DECLARE @chunkCount int = 0;
DECLARE @procRunDate datetime = G...
