October 30, 2019 at 6:11 pm
The Update Failed message reminds me of when I was a database developer some time ago working with Oracle, and the DBA's there programmed some automated job that would e-mail me with the message:
"Error: Job completed successfully."
...so was it supposed to fail but it didn't?
October 30, 2019 at 6:24 pm
Oh boy how I love vendor code. I am not exaggerating to say I just saw this.
try
{
OneLineOfCode;
try
{
AnotherLineOfCode;
try
{
ThirdLineOfCode;
}
catch(Exception ex) {}
}
catch(Exception ex) {}
}
catch(Exception ex) {}It is bad enough that they used the try/squelch anti-pattern but seriously...what is the point of nesting them three deep? Do they actually not realize that the outer empty catch would also catch anything inside? And why did they bother to name the Exception? I guess they don't care about compiler warnings either. The compiler does not like these types of lazy things. There were about 4 more levels of nested try-squelch around all this garbage. But the outer code had a try/catch that displayed an error if one happened. Too bad the class logic prevented the error from getting back. Sigh...I am going to have a stiff drink now.
I just tried something similar and it seems that the outer catch wouldn't catch anything that the inner catch eats. I could be wrong, I just couldn't duplicate the outer catch catching the inner exception, course just using divide by 0 as the error. I seem to think it would have to be rethrown(????). I do get a nag about an unused variable (the exception). Obviously could be me %-)
October 30, 2019 at 6:47 pm
x wrote:I haven't played with net core, do you have any info on the type conversion differences? I can't find anything, weak google fu I guess.
In C# since 5 years ago whether .NET Full Framework or .NET Core the type safe way to handle data coming from Sql Server is to cast/convert to objects in the System.Data.SqlTypes namespace. From the docs:
The System.Data.SqlTypes namespace provides classes for native data types in SQL Server. These classes provide a safer, faster alternative to the data types provided by the .NET Framework common language runtime (CLR). Using the classes in this namespace helps prevent type conversion errors caused by loss of precision. Because other data types are converted to and from SqlTypes behind the scenes, explicitly creating and using objects within this namespace also yields faster code.
Ok that made sense.
Regarding what's possible with .NET Core. It's easiest to show how it works. Here is an example of a .NET Core 2.2 Web API POST method which executes a stored procedure to create (and return) an encrypted user access token:
[HttpPost("sh/login")]
[AllowAnonymous]
[TypeFilter(typeof(JsonResourceResultsHandler), Arguments = new object[] { "fc.api_user_email_login_post" })]
public void PostLoginAsync() { }This POST method within the API Controller takes no parameters, has no body, and returns void. The stored procedure follows a common pattern for all Sql Inserts (or Restful POST, or Create CRUD, etc...). The generic class JsonResourceResultsHandler handles the Sql request in the lowest overhead way (bypassing UI/CLR binding and type conversions) while still making use of .NET Core Authentication and Authorization. Json is used for all inputs and outputs. All that's necessary to wire up a new API end point is to map a stored procedure to a route.
So is the class JsonResourceResultsHandler your own class(?) or part of the api? Couldn't google it %^)
Don't bother explaining if it needs lots of work because it'll probably sail over my head LOL
Interesting stuff!
October 30, 2019 at 8:21 pm
For the meat cookers: https://www.engadget.com/2019/10/25/harvard-barbecue-desora-kamado-joe-cinder-grills/
Interesting article. Thanks for thinking of us Steve. I find it kind of funny that they talk about how Traeger and other pellet smokers aren't cheap. Traeger's run from about $450 - $1,200. The Kamada Joe (their cheapest) is $1,699 and the Pro Joe (the top model) is $3,699. They seem to have missed the part about being pricey. And my complaint about ceramic smokers is the cooking surface is microscopic. The Kamada Joe's cooking surface is an 18" circle. That means you can only fit a single slab of ribs on the smoker at a time. With a rib rack you can maybe 5. I like to feed a lot of people when I fire up my smoker. I typically smoke 3-4 different meats at a time. Last time I smoked 6 slabs of ribs, an entire pork belly of pork belly burnt ends, 8 beef short ribs and 2 chickens. I would need four of those big ceramic smokers to cook that much.
All my negative comments aside, the times I have cooked on ceramic smokers the results are mighty impressive. Super consistent heating and smoke penetration is great.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
October 30, 2019 at 8:25 pm
I just tried something similar and it seems that the outer catch wouldn't catch anything that the inner catch eats. I could be wrong, I just couldn't duplicate the outer catch catching the inner exception, course just using divide by 0 as the error. I seem to think it would have to be rethrown(????). I do get a nag about an unused variable (the exception). Obviously could be me %-)
That is really my point. What is the point of all those inner catches when the outer catch just swallows any exception. Removing all of the inner ones would result in the same result (a useless result) with a lot less code.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
October 30, 2019 at 8:36 pm
x wrote:I just tried something similar and it seems that the outer catch wouldn't catch anything that the inner catch eats. I could be wrong, I just couldn't duplicate the outer catch catching the inner exception, course just using divide by 0 as the error. I seem to think it would have to be rethrown(????). I do get a nag about an unused variable (the exception). Obviously could be me %-)
That is really my point. What is the point of all those inner catches when the outer catch just swallows any exception. Removing all of the inner ones would result in the same result (a useless result) with a lot less code.
My point was that the inner catch did the eating if the error was in the inner try, not the outter, unless I'm not getting the same situation coded. Based on my test (if not in error), the outter catch will only eat, if the outter try is the one with the error, so the inner try never runs any statements at all. Sure, if the workload in its entirety is a transaction that rolls back then its moot no matter what, but oftentimes theres some local bit twiddling going on.
If the outter catches, then NO code in the inner try runs, erroneous or not.
October 30, 2019 at 8:39 pm
So is the class JsonResourceResultsHandler your own class(?) or part of the api? Couldn't google it %^)
It's part of a C# library called JsonAutoService I developed originally to help migrate a couple of .NET full framework API's to .NET Core. The full framework API's I'm responsible for have/had (migration is in progress) lots of methods which use ADO.NET to call stored procedures. Instead of continually updating and maintaining all that code (which basically are just type conversions) this library replaces it with nothing by just using Json as the messaging medium. The plan is to open source the library and make it available via Nuget.org. I'm having to figure out what all of that entails tho. It's going to require a lot of documenting and explaining. Maybe Youtube videos.
Here's the implementation of JsonResourceResultsHandler. The injected service class JsonAutoService contains a set of methods to execute sql statements, to return outputs to SqlTypes in C#, and to handle logging errors and exceptions.
using JsonAutoService.Service;
using JsonAutoService.Structures;
using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.Extensions.Options;
using Newtonsoft.Json;
using System;
using System.IO;
using System.Threading.Tasks;
namespace JsonAutoService.ResourceHandlers
{
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
public class JsonResourceResultsHandler : Attribute, IAsyncResourceFilter
{
private readonly JsonAutoServiceOptions _options;
private readonly IJsonAutoService _jsonAutoService;
private readonly string procName;
public JsonResourceResultsHandler(IOptionsMonitor<JsonAutoServiceOptions> options, IJsonAutoService jsonAutoService, object procName)
{
this._options = options.CurrentValue;
this._jsonAutoService = jsonAutoService;
this.procName = procName.ToString();
}
public async Task OnResourceExecutionAsync(ResourceExecutingContext context, ResourceExecutionDelegate next)
{
var httpContext = context.HttpContext;
var request = httpContext.Request;
var user = httpContext.User;
//Serialize Routes
var jsonRoutes = JsonConvert.SerializeObject(context.RouteData.Values);
//Serialize Headers
var headerDictionary = _jsonAutoService.GetHeadersDictionary(request.Headers, user);
var jsonHeaders = JsonConvert.SerializeObject(headerDictionary);
//Get connection string
var sqlConnection = httpContext.Items[_options.ConnectionStringName].ToString();
//Handle request
using (var reader = new StreamReader(request.Body))
{
var body = await reader.ReadToEndAsync();
switch (request.Method)
{
case nameof(SupportedMethods.GET):
var getResponse = await _jsonAutoService.SqlGetAsync(sqlConnection, jsonHeaders, procName, jsonRoutes);
context.Result = _jsonAutoService.JsonGetContentResult(getResponse.ToString());
break;
case nameof(SupportedMethods.PUT):
var putResponse = await _jsonAutoService.SqlPutAsync(sqlConnection, jsonHeaders, procName, jsonRoutes, body);
context.Result = _jsonAutoService.JsonPutContentResult(putResponse, _options.Mode, _options.ErrorThreshold);
break;
case nameof(SupportedMethods.POST):
var postResponse = await _jsonAutoService.SqlPostAsync(sqlConnection, jsonHeaders, procName, jsonRoutes, body);
context.Result = _jsonAutoService.JsonPostContentResult(postResponse, _options.Mode, _options.ErrorThreshold);
break;
case nameof(SupportedMethods.DELETE):
var deleteResponse = await _jsonAutoService.SqlDeleteAsync(sqlConnection, jsonHeaders, procName, jsonRoutes);
context.Result = _jsonAutoService.JsonDeleteContentResult(deleteResponse, _options.Mode, _options.ErrorThreshold);
break;
case nameof(SupportedMethods.HEAD):
var headResponse = await _jsonAutoService.SqlHeadAsync(sqlConnection, jsonHeaders, procName, jsonRoutes);
context.Result = _jsonAutoService.JsonHeadContentResult((bool)headResponse);
break;
default:
context.Result = _jsonAutoService.JsonDefaultContentResult();
break;
}
}
}
}
}
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
October 30, 2019 at 8:46 pm
My point was that the inner catch did the eating if the error was in the inner try, not the outter, unless I'm not getting the same situation coded. Based on my test (if not in error), the outter catch will only eat, if the outter try is the one with the error, so the inner try never runs any statements at all. Sure, if the workload in its entirety is a transaction that rolls back then its moot no matter what, but oftentimes theres some local bit twiddling going on.
If the outter catches, then NO code in the inner try runs, erroneous or not.
But ALL of the catch blocks are empty. So why bother with writing all the inner empty catches at all? Any exception thrown there would be caught and swallowed by the outer empty catch. Their code does not have any transaction logic and it all just blindly assumes that the code before it worked as expected. I could see an argument that you want the rest of the code to continue working. But for that to make any sense at all there should be something in the catch blocks so somebody knows that something went wrong.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
October 30, 2019 at 9:14 pm
x wrote:My point was that the inner catch did the eating if the error was in the inner try, not the outter, unless I'm not getting the same situation coded. Based on my test (if not in error), the outter catch will only eat, if the outter try is the one with the error, so the inner try never runs any statements at all. Sure, if the workload in its entirety is a transaction that rolls back then its moot no matter what, but oftentimes theres some local bit twiddling going on.
If the outter catches, then NO code in the inner try runs, erroneous or not.
But ALL of the catch blocks are empty. So why bother with writing all the inner empty catches at all? Any exception thrown there would be caught and swallowed by the outer empty catch. Their code does not have any transaction logic and it all just blindly assumes that the code before it worked as expected. I could see an argument that you want the rest of the code to continue working. But for that to make any sense at all there should be something in the catch blocks so somebody knows that something went wrong.
I gotcha! In the little test I tried, I could see which block ran, and could see that the outter catch did not actually catch anything, so I just couldn't duplicate "Any exception thrown there would be caught and swallowed by the outer empty catch", because in my case it was swallowed by the catch that matched the erroring try, and the outter catch didn't catch anything. Its probably not an important distinction in any case except for pendants like me 🙂
October 30, 2019 at 9:20 pm
I gotcha! In the little test I tried, I could see which block ran, and could see that the outter catch did not actually catch anything, so I just couldn't duplicate "Any exception thrown there would be caught and swallowed by the outer empty catch", because in my case it was swallowed by the catch that matched the erroring try, and the outter catch didn't catch anything. Its probably not an important distinction in any case except for pendants like me 🙂
It is an important distinction as there could be reason to use an inner catch. But in this example it was just nested for the sake of being nested. So much effort for no result. 😉
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
October 30, 2019 at 9:28 pm
scdecade interesting stuff! If / when you get a public project going you should drop us a note!
October 30, 2019 at 9:33 pm
regarding the SSDT mess, I had studio 15 installed so I could follow one of our developers efforts, but then I went and installed a local SQL 16 and plus had ssms 19. So then when I went to install the data tools for SSIS, some CLR-sounding gadget was too recent. So idiot me went and installed studio 19 with the assumption that then SSIS would work only to run into difficulties even finding it in whatever passes for the "extensions" mess they now talk about.
October 30, 2019 at 10:32 pm
scdecade interesting stuff! If / when you get a public project going you should drop us a note!
Thanks! Yes I'm going to hopefully come up with a plan. At this point I'm kind of not knowing what steps to take. We'll see I guess
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
October 31, 2019 at 9:22 am
The Update Failed message reminds me of when I was a database developer some time ago working with Oracle, and the DBA's there programmed some automated job that would e-mail me with the message:
"Error: Job completed successfully."
...so was it supposed to fail but it didn't?
That reminds me of a developer that I worked with, who once said:
"It works, but I know why".
October 31, 2019 at 9:28 am
Chris Harshman wrote:The Update Failed message reminds me of when I was a database developer some time ago working with Oracle, and the DBA's there programmed some automated job that would e-mail me with the message:
"Error: Job completed successfully."
...so was it supposed to fail but it didn't?
That reminds me of a developer that I worked with, who once said:
"It works, but I know why".
Ba dum dum! Ching!
Viewing 15 posts - 64,126 through 64,140 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply