|
|
Use a DataSet and fill it with each table and set a DataRelationship. Although it may use more memory depending on how much data you have it beats 10000 individual queries.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Could you show some of the schema?
|
|
|
|
|
All queries are done from the same table (lets call it "parts_table").
Let say I start with "part_ID" = 1001 --> query returns 120 "subpart_id" (1002, 1004, 2030 ...)
then i execute same query 120 times and get n subparts for each of 120 subpart_ID from first query and so on
until there are no subparts left. As you can see the number of queries can increase very fast ...
Table: "parts_table"
id part_id subpart_id
1 1001 1002
2 1001 1004
3 1002 2150
4 1002 3250
5 1004 1250
.
Part description for "part_id" is in separate table "part_info". I use join to get info for "part_id" ...
|
|
|
|
|
I'm still thinking about it, and one way (with SQL Server 2008) to reduce the number of queries/trips to the database is with a Table Valued Parameter.
|
|
|
|
|
This is the reason we implemented the hierarchy id, using the partid in the hierarchy id has made a tremendous difference. So much so that I am taking the concept to an Oracle database.
I would craft a stored proc that takes a part and returns all the children in one table, using a CTE to do the recursive loop (and I hate CTEs). Then to the presentation formatting in the business layer.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I am working with "SQL Server 2000 SP3 2000.80.760.0" and as I understand it does not support CTE.
Are there any examples for recursive query for "SQL Server 2000" ?
|
|
|
|
|
hi guys, i'm looking for all over the internet i a just cant find it, i am almost giving up... So, how can i desable a menustrip item from another form. ex: i have a form1(mdi) and i open inside it a form2, and from this form2, i wanna desable a form1 menustrip item. thanks
sorry for the bad english.
|
|
|
|
|
Rather than trying to do this directly, you may which to look into using an application level state engine to which both forms can subscribe. Then whenever a form receives focus it can update its UI state to the configuration contained in the state engine.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
|
Sorry. I should have been clearer.
You can create a static class (public static class ClassName) where you store the values. If you place this class in your UI project, you can use it to store properties relating to the visibility of controls. (ie. public static bool thisControlIsVisible{ get; set; }). In your forms, you can use the appropriate event handler for gaining focus to coordinate the visibility or enabled states of controls on a given form.
Example. In Form1, an action taken by the user requires that menustrip item in Form2 be disabled. Form1 will set a variable in the static state class indicating this. When Form2 receives focus, it will automatically check these values and update itself appropriately.
Some people may suggest that you use the App.Config file for this purpose, but I would strongly suggest you not do that because the changes you effect to the app.config at runtime will be maintained and used the next time the application is run again.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
ok, thank you very much!!! it was a very good answer
|
|
|
|
|
You can setup a method in your Form1 that would enable/disable your MenuItem. I.e. :
public Form1 : Form
{
...
public void SetMenuItemState(bool enabled)
{
myMenuItem.Enabled = enabled;
}
...
}
Then, in your Form2, you just have to call this method using the MdiParent property :
public Form2 : Form
{
...
public void AnyMethod()
{
((Form1)this.MdiParent).SetMenuItemState(true);
}
...
}
|
|
|
|
|
thank you vary much... works great!!!
|
|
|
|
|
You're welcome. Don't forget to vote if you found the answer useful.
|
|
|
|
|
I have a problem with this as Form2 is far to tightly coupled to Form1. This is a good solution for a beginner to use as it is simple, but when a project scales up, I would suggest against this tight coupling method.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Agreed.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Sure, but with what was given, I can't think of another fast solution than that one.
If you want to give a more elegant/universal solution and explain it, feel free to do it I won't.
Edit : and, in fact, you did in your previous post Your solution is obviously valid, and much smarter than mine if the base requirement is an evolutive application.
modified on Tuesday, December 21, 2010 2:48 PM
|
|
|
|
|
I apologize if my previous reply came across as harsh to your answer. As this site is about experienced developers teaching and helping less experienced developers, I was reading between the lines of the question and tried to provide an answer along the lines as I would if one of my juniors approached me with this question on an enterprise level application. As any experienced dev knows, there are many ways to solve day to day problems in code like this. Answers aren't even about which is better or worse.
Every decision in development is about gain and loss. For example, in your solution, your loss is in scalability and sustainability, but your massive gain is in the time and simplicity of implementation in the given scenario. My solution has massive gains in sustainability and scalability, but takes much longer to develop upfront.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
No problem Marcus No it's up to the OP to choose the one that best suits its needs.
|
|
|
|
|
I do not see how this solution is any different from your static class. Sure, your not communicating directly with Form1 with your static class but you are still referencing properties used by Form1.
Plus if you call a function in form1 from form2 you get instant result (without need for focus) - you could also create an event in Form2 that form1 responds to.
I don't claim to have a better solution, just wanted to see if you could justify why the static class is a better option?
return 5;
|
|
|
|
|
Hey musefan,
The difference is the coupling between classes. The static configuration class has an application level scope, so the two UI form classes are complete decoupled with no knowledge of each other and that is the ideal way to develop forms like this. Granted that in the question here, we are dealing with a really simple scenario which is definitely satisfied by form1 setting a value in form2 directly. If and when the project grows, will Form1 have to know about Form2 and Form3 and Form4, but not Form5? Is the setting being changed in each form, or only 1, or 2? With a static configuration class Form1 only has to know about updating one ui based property in it and any class that needs knowledge of that value can simply read it when they need it. It makes for a much cleaner, stable, sustainable, and quicker executing code base.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
But if Form1 has a function for settings whatever that any other form can call then no it does not need to know about Forms 2, 3 and 4 etc.
Also, with your approach of a static class. What if there are multiple instances of Form1? These may need different enabled states for controls and cannot therefore rely on a static class
BTW - I didn't vote your post
return 5;
|
|
|
|
|
But then Forms 2, 3 and 4 have to know about Form 1. What if somewhere in the future, another form gets created that can open Forms 2, 3 and 4. Now Forms 2, 3 and 4 need to have their code updated in order to deal the the new form, or Form 1 and the new form would have to be updated to inherit a common interface. The configuration settings class would need to be static in a standard winforms environment, but in the mdi environment, the config class could easily be instanced and sent around to the form constructors as a reference so that it is instance specific, but still allowing the forms to be decoupled. My point is that I have serious issues with having ui forms coupled tightly to others. The ui objects should be independent of all others and sharing of information should be done with "domain" level classes. It comes from years of "fixing" enterprise systems that were written with that tight coupling. I have a very good understanding of the pitfalls associated with this.
Anyhows.... I'm rambling because I'm bored and I have to be at work to hold the fort this week... Happy holidays to you.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
But then if there is multiple forms that can open forms 2, 3 and 4 then they are likely to have a different UI, which means different properties in your static class and therefore you still have to update code in Forms 2, 3 and 4 to account for this.
I do agree with you about the disadvantages of linking forms in your scenario of Forms 2, 3 and 4 can be opened by multiple forms and they need to disable controls in there parent. But regardless of the methods mentioned here, they all require Forms 2, 3, and 4 to be updated when any new Parent Forms/Controls are created
The way I see it is that if Form 2 needs to disable any controls in Form 1 then the 2 forms are already quite related (even if not directly by code). Therefore I see the best logic in being that anything in Form2 that determines that state of controls in Form1 should be presented as a property/method. Then Form1 can query the values at any time and update its own control state (perhaps an update event or if it is a Dialog then on close/result)
So...
Form2 has a property InvalidData
Form2 has an event Update
Form1 listens for Update event and then if InvalidData then disable control
...but then when Form3 pops up, you have to update code in Form1 to check state of new Forms properties. I just cannot think why a child form would need to disable controls in a parent unless that form was specifically created for that parent form alone
Oops, now I'm rambling. Happy holidays
return 5;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
