Return Error messages from SQL Connector

Product Suggestions
1

I’m using SQL queries to communicate with Postgres databases. Sometimes, these will fail and result in a Tulip Player error message saying that the Connector has failed. I’d like to get these error codes.

I reached out to Tulip Support, and got the following back: “Postgres and other databases often have a variety of error codes and reasons for a single failure, and it could be quite an undertaking to translate and manage all of them into user-friendly error messages.”, which makes sense.

Originally, I had asked for the ability to return error messages similar to the HTTP Connectors. As this level of granularity is likely not feasible, I’d instead like to request the ability to perform an action / change a variable when a Connector has failed.

For example, I run a loop of values that are fetched from a given datetime onward. If one throws an error, I don’t want it to update my last datetime checked to now, as I will have missed that record (and without notice). Essentially, I want an error detected flag so that I won’t update my datetime checked (and will allow me to email, etc. someone in charge to remedy the issue).

I’m not 100% what this will look like (there are a lot of things in the works), but I’m open to discussion.

2

I agree, to get the error would be great.

However, what you should always do is, clear the variable, the connector function result is meant to put in.
Then run the function.
Only deal with the result, if the variable is not empty.

That prevents writing wrong data, when connector function failed.

3

Hey @Preston -

Let me check with the team to see if it is feasable to allow status codes to be mapped to outputs, much like we do with HTTP connectors so you can catch these cases. @thorsten.langner’s suggestion is a good one, and a common pattern we see across customers.

Pete

2 Likes
4

While I follow this principle for most cases, in these cases I’m writing data to a Postgres table (so no return value).

If it’s an update write, then I’d need to also introduce a date modified (or similar) for a follow-up check to make sense, which is more overhead than I’d like.

100% agree that that’s how things should be handled when you’re returning data, but the alternative (posting data) is a different story.

Thanks gents.

5

Yes…That’s 100% true