We as software developers have a need to write logs so that our support department as well as ourselves have some information as to why some processes might not be working as expected. One standard moment to write to a log would be within a catch clause... now the SF generates (most of) our catch clauses, so the only way for us to log caught messages would be if Thinkwise provides us with a standard way of logging (which is called from the generated catch clauses by default). But of course we also need to be able to call the log procedure ourselves. The most important thing to factor in here is that most issues get rolled back, undoing any logging in the process if not implemented correctly.
I'm thinking of a procedure (something like dbo.tsf_write_log) which at least takes a message (nvarchar(max)), but maybe also other stuff, like procedure name or the likes of that. Of course things like a timestamp get added automatically by the logging procedure
Page 1 / 1
Hi Pim, it seems like you guys at Acto are really keen on this feature 
.
Do I understand correctly that you want to log errors in the end product database, since you are talking about rolling back transactions?
The way we look at logging (and monitoring) of applications, this is more the responsibility of the Indicium application tier. That way, not only errors in code but also errors in CRUD actions, database calls (like parameter or data type mismatches) or process actions are logged.
The error handling code in, for example, stored procedures is only used to rollback the transaction, after which the error will be re-thrown and logged in Indicium. The Indicium logging can then be viewed in IAM and/or Application Insights.
I like the idea of sending custom events from code to the Indicium application tier however!
Kind of like how SQL print statements are shown in the debug window of the Windows user interface.
.Do I understand correctly that you want to log errors in the end product database, since you are talking about rolling back transactions?
The way we look at logging (and monitoring) of applications, this is more the responsibility of the Indicium application tier. That way, not only errors in code but also errors in CRUD actions, database calls (like parameter or data type mismatches) or process actions are logged.
The error handling code in, for example, stored procedures is only used to rollback the transaction, after which the error will be re-thrown and logged in Indicium. The Indicium logging can then be viewed in IAM and/or Application Insights.
I like the idea of sending custom events from code to the Indicium application tier however!
Kind of like how SQL print statements are shown in the debug window of the Windows user interface.
Hi Jasper,
It doesn't have to be in the database, this was just one of the options. My comment about rollbacks was to indicate I have done some research into logging and found logging into the dabase to not be trivial.
I think making Indicium responsible for all logging is a good idea, except for when we're developing (without Indicium in between). Although I must say the Indicium logs are very cluttered at the moment (with all the huge stacktraces that I have no use for).
Right now we have two real needs:
It doesn't have to be in the database, this was just one of the options. My comment about rollbacks was to indicate I have done some research into logging and found logging into the dabase to not be trivial.
I think making Indicium responsible for all logging is a good idea, except for when we're developing (without Indicium in between). Although I must say the Indicium logs are very cluttered at the moment (with all the huge stacktraces that I have no use for).
Right now we have two real needs:
- We need to write into the logs what and when we want, but the way I read it you agree this is a good idea.
- We need to be able to access these logs whenever we want. This is a bit of an issue, since we have limited access to production environments. You say this should be available in IAM, but I have not found any such logging in IAM (unless this is hidden within the user sessions (although where would I then see external access to Indicium)).
Hi Pim,
I also think that this is a pretty good idea. The infrastructure for processing messages, even informational ones, sent from the database is already largely in place. After all, Indicium already responds to tsf_send_message and passes these messages to the client. We would just need to design a way to differentiate between messages that are meant for the client and messages that are meant for logging, but we can think of a convention for that which we can hide behind a separate function.
We have also done some work already on making logs more accessible, so that's going to be useful for this as well. It would still take a little while for something like this to be finished though, once we decide to pick it up.
I also think that this is a pretty good idea. The infrastructure for processing messages, even informational ones, sent from the database is already largely in place. After all, Indicium already responds to tsf_send_message and passes these messages to the client. We would just need to design a way to differentiate between messages that are meant for the client and messages that are meant for logging, but we can think of a convention for that which we can hide behind a separate function.
We have also done some work already on making logs more accessible, so that's going to be useful for this as well. It would still take a little while for something like this to be finished though, once we decide to pick it up.
Updated idea status On the backlog → Planned
Updated idea status Planned → Working on it!
Updated idea status Working on it! → Next release
Updated idea status Next release → Completed
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.