Comments by Michael Breeden (Top 19 by date)

Awesome Richard... Obvious in hindsight, but a simple mistake. Thank you much!

I'm using jquery-1.8.2.min.js, but now that you mention it, I'll try with jquery-2.2.0.min.js ... No Help. Sew... let see what happens if I individually disable and enable all the controls instead.
(1)comment out the code:
$(document).keydown(function () { return false; });
That fixes the problem, though it does not explain it...
With breakpoints disabled, the response is almost instantaneous, so I'm not sure just what to try to disable that is going to help. It's a simple form. Ahhhh. The button could inadvertently be clicked twice (does an html switch have bounce like a mechanical switch does? :) ). The date picker though could not be used in the time it takes for the AJAX response to complete.

Yes. I'm reading the value in the textbox and sending it with AJAX. It works the first time, then the text box becomes "read only" or "disabled", but I can update other controls and re-run the AJAX process. All data is read and sent correctly including the data in the text box. I just cannot modify that data.

No, there's nothing in the console. (Using Chrome Developer Tools.) ... That was a good call. I tested in FF and there is nothing in the console but what I put there.

Jörgen Andersson - Very interesting. I basically know most of this stuff, but you and some others know it far more solidly than I do and can say why it is so. It's funny that I am really not good at SQL, not even as good as many C# developers, but some good database people have on occasions told me very good stuff and I try to remember it.

Cool, this is great. It allows me to use parameters, but only when I want them. This is super adaptable.

>>>3) At least in my tests using normal sql code was faster than using stored procs in any db post 2005.<<<
Interesting, I had heard they were very similar, with possibly an edge to a stored procedure. Still, due to past risks of SQL Injection, some shops absolutely forbid using SQL Statements instead of Stored Procedures... I'm not even using parameters, so I am just hoping no one notices.

>>>it requires a connection open for longer (the life of the Reader) and "hogs" Server resources <<<
That is the key thing I was concerned with and why the code to use the DataAdapter is only commented out, not removed. I may even make which is used configurable.
As for "select top 20", this is processing to a fax number. I might get 100 records with the same fax number, but I only allow 3 in my system at a time. That means only 1 of 100 fax lines could be put in use until I get records with different fax numbers. I would need a statement something like "select top(100) faxnumber is distinct" ... may have to ask a DBA around here if that can be done... a group clause maybe... Hmmmmm.
I suspect that using an "exec" statement might torque someone as well.

Apparently I caused a misunderstanding. My objective is to log the person off the application if they are not using the computer - "user activity" - which appears to be a security issue - rather than if they are not using the application. If they are still using the computer, I expect it is the same person. My concern is if they walk away from the computer or forget it somewhere. If they are using it for something else other than my application, I am assuming they are still in possession of the machine. If the machine is not being used ... then I want the logoff.
Is there any other disadvantage to using this code?

#2. Fascinating. Didn't know was race condition, but the memory is very old.
I'm going to mark as answered and I do thank you for your time and expertise. I think I got the understanding I was looking for. Do you recommend an article on Interlocked for #1? Thanks again, Mike

I'm sorry, but I must be explaining my intent very badly and you seem to be solving the trivial problem I present with a sledge hammer. I think this question is a bit too simple minded for you.
How about this? Please use the numbers and tell me if they are correct or incorrect. You do seem to have a deep enough knowledge of this to know these fine points.
1. As far as I know, there is no inherent reason that a normal variable cannot be read/write by two threads as long as it is in the scope of both (parent and child thread...).
2. If two threads try to write to the same variable at the same time, there can be a problem of creating an indeterminate (random) value in the variable. There will be no exception though.
3. If two threads try to read from the same variable at the same time, there should be no problem and the correct value will be read.
4. Even if two threads try to write to the same variable, but at different times, there should be no problem, no exception and the value of the variable will be correct after the individual writes.
5. If one thread writes to a variable and another reads the variable, even at the same time, it will not lead to an exception or an indeterminate value. It will be the value of the variable either before or after the write.

Really, I'm trying to build a wagon, not a race car. It is not about data, it is about flags controlling application behavior. I'm just trying to find out some details about what some thread behavior would be without using locking. All I have to work with are very old memories from basic classes.

The last point is the easiest to answer. This is being developed in a Windows Forms application, but the classes are structured so that it could run in a console or Windows Service. The classes that do the work, do not "talk back" to their parents at all, though the parent (form, console, service) can get or set values in the thread.

As I mentioned, I can use a the thread safe ConcurrentDictionary or even a couple of Interlocked.Increment operators and be thread safe instead of using locking, but I am really more curious about if there would be a problem using:
1. A normal dictionary if only one thread will ever write to a a keyValuePair in it, though another thread will be doing the read.
2. A normal property (string) if only one thread will ever write to it, though another thread will be reading it.

Thanks, Mike

Sir, thank you for your expertise. I am constructing a test application from the above code (LOL) and will test it with different scenarios including 1. The thread wrapper you pointed me to, 2. A concurrent collection (I expect a performance problem) and 3. Not putting the classes in a collection, responding to an event on thread completion. I will post the result

Well I want it available for basic ASP.Net Authentication and Authorization, which you can do without SQL Server, but it would be more convenient with it.
Plus, while MySQL can be used as a database, it's quite limited and does not greatly lend itself to Entity stuff (Yes there does seem to be an adapter available, but just more hassle and I get buried keeping track of configurations.) I'm getting more into MVC / LINQ and they want SQL Server.
... I think I understood your question. It is about my application using data in the MDF file, not a user having access to the file.