I have already explained more than once. When you call cmd.ExecuteNonQuery(); you must check the return value, to see whether the SQL command succeeded. Only when you have a success return can you post a message that tells the user that his action has worked. You must do this on all database access commands, never assume that your code has worked - most of the time it has not.
Yes, it shows login successful because, as I keep repeating, you post that message even when the ExecuteNonQuery fails. You need to start thinking about your code in logical steps rather than just throwing statements together and hoping it will work.
1. Perform the ExecuteNonQuery, and capture the return value.
2. Does the return value indicate success?
2.1. No - tell the user it failed.
2.2 Yes - and only at this point, tell the user it succeeded.
3. Perform other actions.
I am so glad I didn't answer this question last night.
You're not trying to think about the problem. You're not trying to read the documentation on the methods you're calling. You're not trying to read the links other people have given you to educate you on what you should be doing. You're not trying to work out what you should be doing, logically, step-by-step. You're not trying to understand anything.
What you ARE trying to do, throughout this entire thread, is get other people to write your code for you, and that will teach you nothing.
I have a multi-layer application (user interface, business objects, data access layers). The business objects are inter-related as you might expect, so a "Group" has a property that returns an array of "Users", and each User may have multiple "Events" and each Event can have multiple "Locations" for example. Ultimately the data is accessible via a website which makes extensive use of webservices to load data dynamically. All is well and good and when a webservice loads an Event it gets all that event's Locations returned in the auto-generated JSON. When the webservice returns a Group object it also returns the list of Users, and for each User all their Events, and for each Event all the Locations. Which very quickly gets unwieldy! Not only does it make the webservice response very large, but the database is hit very hard (most of the properties are "lazy loading" so, in the rest of the application, a group's Users are loaded only when explicitly referenced, but the JSON serialization accesses ALL the properties of Group, so...)
I can control this to an extent by decorating some properties with [ScriptIgnore] (which I had to do to break some circular references; e.g. the User object has a reference to its owning Group).
However what I really need is a way to customise which properties are included depending on the context. For some webservices, all I need is the top-level object (e.g. Group), but for others I need all the Users in that group as well. Sometimes I only need a small subset of the properties of Group.
I've looked at creating very simple classes that contain just the items I need, and creating a property in the main class that populates and returns that simple class, but that seems like a lot of effort for each use case. Is there any way to use custom attributes on the properties such that I can specify an attribute name at run time and have the serializer include only matching properties?
yes, quite; but it's whether you can then use those attributes at run-time, as a sort of "selector" for which properties to serialise.
Using a separate DTO for each use-case seems like overkill, and having experimented with just one required much more coding than I'd like to do. It also means rebuilding the business layer DLL if I need to add in a property or create a new use-case.
I rather suspect that since there are quite a number of objects, each with a couple of different use-cases, the simplest thing (development-wise) might be to just build up the JSON response "by hand" as it were, and simply return the JSON string to the caller rather than having it built dynamically by the serializer. Then the task of adding a property or two becomes trivial and only affects the webservice methods that actually need to return them.
I'd just hoped there would be an easy way to return an object from a webservice referencing a custom attribute that would act like a "where" clause to select the properties I need... This is a personal "side" project so don't want to spend too much time on it and if a "quick and dirty" solution works, so be it...
It's an object graph (your data model); parent child relationships; you (simply) stop retrieving at the appropriate level and use empty collections for those children you don't retrieve.
That's all in the data access layer; which follows your data model.
I'm not a big fan of "giant, one line SQL / LINQ queries", and usually get superior results with chaining a number of subqueries; which makes serializing simple using one generic "object" serializer / deserializer.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
And therein lies the problem - how do you determine the levels to retrieve, when the object is being serialised by .Net in the webservice response processing?
In fact the way I've written it, the lower levels are only retrieved if the collection is null rather than empty. This means I could populate the object, then set the "unwanted" collections / properties to an empty object / array, before letting .Net serialise it. However that does work for non-nullable properties, which will still get serialised (with their default values) when actually I just don't want them at all. I also realised that there are some items which are confidential (e.g. user email address) and while I don't normally want that serialised, there are occasions (when invoked from an admin page and with security in the webservice itself) when I do.
I'm just a bit surprised that JSON serialisation (and by implication XML too) doesn't have a bit more dynamic control / management. That said, it's very very much simpler these days than when I first started writing AJAX applications in 2003 (before the term AJAX had been coined; I was just using raw xmlHttpRequest objects and classic ASP pages at the server...)