Hi,
Here's a really long blog post of a new kind. Trying to share, not a technique, but a way of thinking. If you have time, I'd really like to know if you find this interesting (Noes are as valuable are Ayes)
Thank you!
Hi,
Here's a really long blog post of a new kind. Trying to share, not a technique, but a way of thinking. If you have time, I'd really like to know if you find this interesting (Noes are as valuable are Ayes)
Thank you!
Nice work.
Just an idea: ExecuteSQL takes variable number of parameters. You could do a call to ExecuteSQL() passing e.g. 20 parameters with variables. Then you could use up to 20 question marks in the SQL and fill parameter variables as needed.
ExecuteSQL ignores additional parameters as far as I know.
Not sure I'm following.
Where would you declare the variables? as soon as some data goes into JSON it loses its type, so it would imply that the variables are declared before calling the function, which introduces a dependency that I wouldn't like to have. Or maybe (probably) I'm not understanding.
Well, for our JSON.InsertRecord and JSON.UpdateRecord functions we lookup the field type for each field to make sure we use GetAsDate, GetAsTime, GetAsTimestamp for values to convert from text to the date/time type.
From a JSON you get numbers and text only, which may be fine. You ma also check field type and do conversion if needed. Or it may be as easy to detect whether a value is a date by checking if GetAsText(GetAsDate(v)) = v to check if it is a date.
Well,
I love you way of thinking ! Your function includes everything AND the kitchen sink, you plug all the holes where something may go wrong. In short yo do the job right at the beginning, without providing something where you can easily tell the user "it's your fault if it does not work".
Congratulations.