|
Sir, How to write mysql query if stored userid password is correct means then it enter successfull suppose not stored values entered means the messagebox is wrong.....
|
|
|
|
|
Why do you ignore everything we tell you? Go back to the code sample I gave you, it shows exactly how to do it correctly. This is my last message on this subject.
|
|
|
|
|
Pls correct and send me in my code sir that why i can understand sir send me please
|
|
|
|
|
How many times do you have to be told "nobody is going to do your work for you" before it sinks in?
|
|
|
|
|
And you are still not checking the result of ExecuteNonQuery , but putting the success message based on the user pressing the "Yes" button.
|
|
|
|
|
How to check it. Please give step procedure sir or video link
|
|
|
|
|
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.
|
|
|
|
|
No sir mysql command was not succeeded, when i am giving wrong userid passwor dit shows login successfull i think sql query to be change
|
|
|
|
|
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 clearly telling again mysql query is error here, ExecuteNonQuery is returned value it means i logged in with wrong userid and password also.
|
|
|
|
|
No, that is not what it means, please read the documentation: SqlCommand.ExecuteNonQuery Method (System.Data.SqlClient) | Microsoft Docs[^]. When you use a SELECT to find a particular user id and the return value says that there is an existing row it means that the details are correct.
However since most of your code is in the wrong order it is unlikely that any of your results are correct.
|
|
|
|
|
Sir, You all are blaming me always, you know the code but you are not providing me. Thank you all.
|
|
|
|
|
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.
|
|
|
|
|
Sir, Now you give the right code or not?
|
|
|
|
|
See, you're STILL trying to get other people to do your work for you.
The answer to that very question, from EVERYONE, is going to be NO. The only code you get is the code YOU write.
|
|
|
|
|
Waste of time in this forum. Bye
|
|
|
|
|
It's a waste of time only because YOU made it that way by begging other people to write your code for you.
|
|
|
|
|
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?
|
|
|
|
|
You can't change attributes at run-time; they're compiled into the assembly.
You can either create custom DTOs, use anonymous types, or create one or more custom JSON converters.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: You can't change attributes at run-time; 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...
Thanks Richard!
|
|
|
|
|
As I said, an anonymous type should work:
public async Task<IActionResult> Get(int id, CancellationToken cancellationToken)
{
Group someGroup = await context.Groups.Include(g => g.Users).FirstOrDefaultAsync(g => g.Id == id, cancellationToken);
if (someGroup is null) return NotFound();
return Ok(new
{
someGroup.Id,
someGroup.Name,
someGroup.SomeOtherProperty,
Users = someGroup.Users.Select(user => new
{
user.Id,
user.Username,
user.EmailAddress,
}
});
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
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
|
|
|
|
|
Thanks Gerry.Gerry Schmitz wrote: stop retrieving at the appropriate level 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...)
|
|
|
|
|
Normalize your dataset. Classes will follow.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Not sure that's really a solution to this particular problem. There are use cases where I want certain related objects, and others where I don't. There are multiple combinations of multiple objects. I guess it might be possible to artificially construct classes that have the required lower levels in various combinations, but that would be bringing aspects of user interface design over into the class structure of the business layer - and in turn that affects the data access layer. Adding a further use case could result in massive amounts of rewrite. So pragmatically it's not a solution.
I'm just surprised there's not more control over serialisation!
|
|
|
|