|
am working on a project with the following codes:
Private Sub prono_TextChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles prono.TextChanged
obj = objordder.getIDfrmno(CStr(prono.Text))
cmdPid.Text = Val(obj)
End Sub
where objordder.getIDfrmno is the dll and cmdPid.Text is the destinesion text box
the definetion for objordder.getIDfrmno is as follows:
public object getIDfrmno(int productno)
{
SqlConnection con = new SqlConnection(constr);
string sql = "select ProductID from tblProduct where productno=" + productno + "";
SqlCommand cmd = new SqlCommand(sql, con);
con.Open();
object obj = cmd.ExecuteScalar();
con.Close();
return (obj);
}
constr is the conecction string
but not being able to get the desiered result can anyone hrlp
|
|
|
|
|
Arunava35 wrote: constr is the conecction string
What is the exact connection string you are using?
Arunava35 wrote: but not being able to get the desiered result can anyone hrlp
In what way? Is it giving you an error message? If so, what is the error message. Or is it giving you a blank screen?
Pete Soheil
DigiOz Multimedia
http://www.digioz.com
|
|
|
|
|
it is not giving an error but the result which is being shown is not correct.
|
|
|
|
|
That can only mean that your query is wrong, and/or you didn't take a foreign key relation or something along those lines into consideration.
Pete Soheil
DigiOz Multimedia
http://www.digioz.com
|
|
|
|
|
I am enumerating through a collection where the index is a string. I would like to get my hands on that string.
I am working with regular expression named groups, but the issue is the same for any collection indexed with strings.
An example:
Regex regEx = new Regex(@"^(?<name>\w+):(?<value>\w+)");<br />
Match match = regEx.Match("abc:123");<br />
GroupCollection groups = match.Groups;<br />
<br />
Console.WriteLine(groups["name"]);<br />
Console.WriteLine(groups["value"]);
(Note that the sad face emoticon in the first line should be a colon followed by a left parenthesis. I could not turn this off.)
The above writes the following to the Console:
abc
123
I would like to also write the index so the output looks like:
name = abc
value = 123
Ideally, I would like to use a foreach to print all indexes and values in the collection. This would look something like:
foreach (Group group in match.Groups)<br />
{<br />
Console.WriteLine(??? + " = " + group.Value);<br />
}
I cannot figure out what "???" should be.
Thanks.
|
|
|
|
|
I looked into this and no real solution. Have you found a way to do this?
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
No, I have not found a solution.
I suspect it is buried in the container classes or iterators some place, but I haven't had time to look.
It wasn't a high-priority issue for me, so I am currently doing without.
|
|
|
|
|
kalkwarf wrote: I suspect it is buried in the container classes or iterators some place
I would think so. For fun I am going to dig around at this and let you know if I run across anything 
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
So for the last 11 years or so I've been working to push as much of the query work in the database. So you build an objet that calls a stored proc the gives you the data that you are looking for. So now linq comes out which seems to fly in the face of that. I'm watching some of the videos on msdn and she is doing a bunch of stuff that should really be done in the database.
Am I wrong? I see some uses for link. I like the DAL but I think when you get to using join's in link you have gone too far.
|
|
|
|
|
So you see what happens when you watch too many MS videos. You start all your sentances with "So".
|
|
|
|
|
lol 
|
|
|
|
|
Personally I'm with you, I've always put as much of the data querying and data processing on to the DB as possible (where appropriate of course) because the DB is designed for such thing and is very efficient at handling large data sets.
Linq works on the current trend (.Net included) of making performance trade offs in return for ease of use in the form of productivity and maintainability.
I haven't had a chance to get to grips with Linq yet and really use it in anger so it'll be interesting to find out if it's suitable to use instead of stored procs.
One thing to remember is that Linq is about more than just databases, it allows you to do this querying with XML and even objects/collections which Stored Procs arn't so good at handling 
|
|
|
|
|
So you make it sound like Linq and Stored Procedures are mutually exclusive. I have no experience with Linq beyond reading a few articles but I would find that surprising based on my initial grasp of it.
|
|
|
|
|
Well you could use Linq on a result set returned by a stored procedure, or you could use both in their appropriate places. They arn't mutually exclusive but the OP was saying that the tutorials he's seen have been demonstrating Linq with Sql Server in situations where some people have traditionally used Stored Procs.
I was agreeing that personally I use Stored Procs in those situations but I was also trying to point out the different advantages of Linq and that it's not just limited to Sql Server.
EDIT: PS congrats on your second year as an MVP
|
|
|
|
|
Linq can be used for lots of things beyond just DB stuff. Like as a replacement for XQuery in xml docs and for searching collections.
My point is that if your just searching data from a database, linq probably isn't the best way to do it.
So I think there is a place for linq, but it's not the end all be all.
|
|
|
|
|
Tad McClellan wrote: I'm watching some of the videos on msdn and she is doing a bunch of stuff that should really be done in the database.
Microsoft, I think, try to cater for everyone. So, if you have a small project then LINQ to SQL could be useful. For an enterprise application I wouldn't rely on it.
However, you can use LINQ with stored procedures, so you can continue to keep the querying stuff in the database (where it should be) and use some of the other features of linq to do smaller tasks in the .NET application.
I am very much in the camp that the application should access the database through stored procedures only.
|
|
|
|
|
I tell you where Linq is more interesting - it's the point where you use it to perform joins on collection objects. That's when the fun begins. I agree though that Linq to Sql can lead you to do too much outside of the database and you have to be really careful that you don't pass the data context away from the DAL.
|
|
|
|
|
Pete O'Hanlon wrote: and you have to be really careful that you don't pass the data context away from the DAL.
Why ?
|
|
|
|
|
N a v a n e e t h wrote: Pete O'Hanlon wrote:
and you have to be really careful that you don't pass the data context away from the DAL.
Why ?
If the context is available outside of the DAL, then you can completely bypass the DAL. In other words, you could bind directly to the data from the database. This means that you've suddenly gone from a neat n-tier architecture to one where the GUI has knowledge of the database itself (and this isn't what the GUI is supposed to do). Have a read about the principles behind n-tier architecture and separation of layers.
|
|
|
|
|
Thanks Pete.
Pete O'Hanlon wrote: Have a read about the principles behind n-tier architecture and separation of layers.
Yes I do have basic idea on them. But when it is mixed up with LINQ, I am confused.
|
|
|
|
|
N a v a n e e t h wrote: But when it is mixed up with LINQ, I am confused
You're not the only one. I'm currently working with Marc Clifton to try and define some best practices which hopefully will alleviate some of the confusion.
|
|
|
|
|
You can query your domain objects using LINQ. They can translate the query into a storage mechanism specific query.
Our current query API (in Diamond Binding) is based on the domain objects - so when you use Expressions or OQL you are querying the domain - say Employee.Manager.Name == Fred. This will be translated under the hood into an appropriate SQL query to return a List< Employee >
I think the temptation is there to bypass your DAL, which is bad, mmkay - but allowing your domain objects to be queried ad-hoc (using the _domain_ terms) is a big productivity boost, and doesnt compromise your architecture. Of course this means your DAL has to be 'smart' enough - which generally isn't the case when you are using 'dumb' codegen to spit out a whole DAL.
|
|
|
|
|
|
Oh I agree. The key here is the flexibility of your datalayer and the strength of your design.
|
|
|
|
|
Pete O'Hanlon wrote: I'm currently working with Marc Clifton to try and define some best practices which hopefully will alleviate some of the confusion.
Cool. So I am expecting another great article. Looking forward on reading it
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
