How many times do I need to say it: Do not post a success message when you have not checked the result of your Database query.
This is the way you should do it:
int result = cmd.ExecuteNonQuery(); // always capture the result
if (result == 1)
MessageBox.Show("Login was successful");
MessageBox.Show("The entered details were not correct");
Also, why do you need two ids (userid and loginid)? You should only need a single id and a password.
There really is no point in continuing this thread. It does not matter how many times we tell you how to correct your code you insist on ignoring our advice. My previous reply showed you exactly how to do it correctly, and yet you just repeat the same bad code. I suggest you consider a different career path.
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?
Last Visit: 31-Dec-99 18:00 Last Update: 30-Sep-22 9:08