|
srisravani wrote: implements interface ISortable
Never heard of it.
|
|
|
|
|
Use IComparable to sort something.
Never heard of ISortable
|
|
|
|
|
Hi all,
In my application, i have one arraylist which will store graphicspath object (series of line), let said gp1 (contains points a1,a2,a3),gp2 (contains points b1,b2,b3),and gp3(contains points c1,c2,c3),. These graphic path will be drawn in one drawing area. I would like to ask that how can i know which graphics path was selected when mousedown event occur? Off cours, i have already get the particular mouse point,let said points b2.
And in this situation, does create a region have any help in my problem(i mean create a graphicpath region to determind whether the points is in the graphicspath object)?
any help or tips are welcome 
regards
cocoonwls
|
|
|
|
|
Hi all,
I think i can use graphicspath.IsVisible(points) to determind whether the particular object was selected...
|
|
|
|
|
Hi!
To find out whether a given point is inside the region surrounded by your GraphicsPath, you can create a Region from your GraphicsPath (there's an appropriately overloaded constructor) and then use Region.IsVisible().
If you're interested in whether a point is on or near the outline of the region, use GraphicsPath.IsOutlineVisible().
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
HI mav.northwind,
Thanks for your reply..i will try it
regards
cocoonwls
|
|
|
|
|
I would like to know how to read the bits of a 32bit integer. Say I have 32bit int and I want to read the last 11bits and then 2bits before that. Do I do this:
11bits = (integer >> 21) & 0x7FF;
2bits = (integer >> 19) & 0x3;
Is this correct?
Thanks
|
|
|
|
|
threemp3 wrote: I want to read the last 11bits and then 2bits before tha
If you meant the high order 11 bits and the next two lower order
bits, then yes that's correct.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi,I've got a doozy.
I am the only developer at a fairly large company with a very small IT department.
I was asked to write a small application (sends out notifications when contracts are about to expire - slightly more complicated than that.)
Our previous programmer had been in a word terrible, and since taking charge I had explained enough to my well-meaning but non-technical that he understands vaguely the benefits of OOP, doing things in a modern programming language, and library reuse. He came to me with a concern today - our VP, another well meaning guy but someone who hasn't programmed since the early days of COBOL - wants everything to be done in PL/SQL stored procedures to 'keep as much of our programming in one place' and to have 'fewer applications to maintain' (wtf, right?). My boss could not convince him otherwise and asked me to create a powerpoint presentation on the issue.
I am planning on the following slides:
Benefits of using a modern programming langauge:
Library Reusability (domain object libraires)
Maintenance Clarity
Maintenance Testing (automated tests)
Maintnenace People Cost (nobody programs in PL/SQL! where are they going to find people?)
Tools available (debuggers, etc.)
N-Tier Architecture
Why People Use Stored Procedures - for each one the premise, why its not exactly correct, and why it doesn't apply to us
--User authorizations to use certain ones (we have one user with all authorizations enabled)
--Speed (our bottleneck is overuse of ajax, plus its not really true)
--Security SQL/Injection (parameterized sql and sometimes our SPs build sql as text and then eval it - sigh)
Any advice for doing this presentation? I am really worried that if I have to do this in PL/SQL this is going to become a trend and I will have to quit.
modified on Monday, August 4, 2008 8:16 PM
|
|
|
|
|
I'm glad I'm not the only one here who dislikes stored procedures (or at least the blind overuse of them).
Let me preface:
Before .net I did most of my database application programming with SQL embedded in C, either with Oracle (PRO*C) or RDB.
But at one point I had to work on a project that used SQL Server (6, as I recall) and ESQL was not yet available so we had to use a horrible (consultant-written) library of ODBC routines. The result was that the only way to have transactions was to use stored procedures.
No one was happy about it and thought very nasty thoughts about the sales monkeys who said we'd do it.
While I realize that newer versions of SQL Server offer better security and reliability, I continue to distrust stored procedures:
A) While installing some of my stuff at a client's site, the client asked if I could make a slight change; I did, it was just a small change to a stored procedure... a change to production code outside of source control. I did remember to check in the updated code when I returned to the office, but I realized that any (properly authorized) person could change any of the procedures, perhaps maliciously. Such changes are much more difficult with compiled code.
B) Several times a stored procedure just disappeared! I have no idea how. This either doesn't happen with compiled code, or at least the program won't run at all if it does.
Performance:
A) I can neither confirm nor deny whether or not procedures are faster than queries in strings. I suspect they are, though at best it's only due to preparation time.
Unless you have a procedure that gets called a whole lot (which may well be the case with a Web page), I doubt it matters.
If a procedure gets called less frequently then you're not benefiting from any performance improvement.
If the preparing of a particular SQL statement proves to be a bottleneck, by all means wrap it in a stored procedure.
B) But also remember that a parameterized ADO.net SqlCommand, once prepared, can be reused many times.
So if you have a Windows Service that needs to execute a particular statement many times during its execution (which should last months) it need only prepare the statement once, just like a stored procedure.
On the other hand, if you repeatedly create and dispose an SqlCommand that executes a stored procedure lose out on much of the benefit of having pre-compiled the code in the stored procedure.
C) One of the benefits of a stored procedure is that you can perform some logic on the data without passing it out of and back into the database, but I wonder what percentage of stored procedure actually involve that.
D) Add to that the recent post that pointed out that if you begin the names of your stored procedures with "sp_", SQL Server wastes time looking for it among the system procedures.
E) I have also worked with people who insisted that "metadata" (stored procedured, functions, etc.) bogged down the database. (Crazy as that seems.)
Other points:
A) If I have an application installed at several client sites I can check the installed versions with directory commands.
B) I can deploy a change to client systems with copy.
C) A database restore won't wipe out SQL code in compiled code.
D) I have no idea why someone would write a stored procedure that merely returns a table of data; use a view for that.
I also use quite a few inline table-valued functions; they combine the best of both views and stored procedures.
Closing:
Don't just use stored procedures unthinkingly:
If the statement is a proven bottleneck, first try improving the statement, only make it a stored procedure as a last resort.
A pre-compiled piece of crap is little better than an ad hoc piece of crap. (And it may be more visible to the client.)
Conceptually, a "procedure" has more than one step, and perhaps control statements; if your code is one simple statement I doubt it should be a stored procedure.
"Use the right tool for the right job." -- Scotty et al
|
|
|
|
|
5ed ! It's a great post. Thanks
|
|
|
|
|
I've got to admit, I'm one of the proc adherants. I put a lot of work into the procedures. With the "one liners" that simply do the CRUD I use procs because I have a code generator that creates the procs and the classes to service them. However most of my work goes into serious crunching of numbers in high volume and for this we need to use procs.
I had not considered the security issues of installed apps (I work for a corporate and you need 53 bits of paper to enter the presence of the production servers) based on procedures. I was aware thae using a framework like nHiberante can give you a DB agnostic application but would not consider using it for my apps.
Restore comes under the same criteria as the production server access! I have lost s a proc but thought it was just me, there you go! Having said that my DAL has a GetTableSQL and an ExecuteSQL so I'm not welded to procs.
Thank you for the food for thought, I will no longer go blindly forward!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Frans bouma has something to say about stored procedures here[^]. It's worth reading.
|
|
|
|
|
Thanks, I've been looking for that article for a while. Read it several months ago.
|
|
|
|
|
Togakangaroo wrote: fewer applications to maintain
SP can be harder to maintain, as it's not contained in a visual studio like solution or project. You literally have to search through all 150 SPs to find business logic, and the capability of renaming of column doesn't help.
|
|
|
|
|
Just use LINQ
|
|
|
|
|
Amen to that my brother 
Harvey Saayman - South Africa
Junior Developer
.Net, C#, SQL
you.suck = (you.passion != Programming)
|
|
|
|
|
I'm wondering whether or not Linq is the new embedded-SQL, I might be interested if so.
|
|
|
|
|
I have personally made it my mission to get rid of all but needed stored procs by using LINQ. And guess what, tomorrow I can swap to Oracle* or MySQL* and use the same code!
* Given they have working LINQ query providers.
|
|
|
|
|
I, like a lot of people, use stored procs extensively, mostly on reasonably large databases. Some of the reasons:
Network performance - why push extra data over the network (sp name + parameters as opposed to long sql statement)
Reuse, maintainability and consistency - if you have two applications doing the same query (perhaps with complex joins) and you need to change the query you change (and release) 1 proc, not 2 applications. You also ensure that all versions of the query are consistant and performance tuned - different developers have different skills, not everyone is good at sql.
Performance - I know that paramterised queries are cahced etc, but there are more opportunities for tuning with stored procs (some people may dispute that, thats their opinion)
There are other pros and cons, and everyone has differing opinions. I am possibly biased in that I have been contracting (mostly at large international financials) for many years, and all PRODUCTION applications have to access the database using stored procedures. This simplifies upgrades and bug fixes as you roll out a stored procedure to 1 server (possibly replicated) rather than several applications to users around the globe.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Ashfield wrote: reasonably large databases
It's the statement that matters, not the size of the database.
Ashfield wrote: as opposed to long sql statement
You only need to do that once per application run.
Ashfield wrote: 1 proc, not 2 applications
One DLL, not two EXEs.
Ashfield wrote: users around the globe
Web Service?
|
|
|
|
|
PIEBALDconsult wrote: It's the statement that matters, not the size of the database.
Not totallly, you can get anyway with any old crap on small databases, but I only mentioned database size as background.
PIEBALDconsult wrote: You only need to do that once per application run.
What, even a paramaterised query?
PIEBALDconsult wrote: One DLL, not two EXEs.
Still have to deploy to all users
PIEBALDconsult wrote: Web Service?
Performance?
Sorry, eveyone is entitled to their opinion, I am merely giving my two pennth based on my experience. Other people, as I said, have different opinions and I am fully aware that the financial industry differs in working practices from other industries.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Stored procedures are great, but they are not magical.
You might sometimes get a slight speed benefit from using stored procedures, but the potential is very limited. You can easily get much more speed from other changes.
If you want to keep as much of the programming as possible in one place, the database is definitely not the place. Robust and maintainable code is better written in a compiled and object oriented language. Your stored procedures should query data, and little more.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
I gave you a 5 even though I don't agree with
Guffa wrote: stored procedures should query data
|
|
|
|
|
I use store procedures a lot, never thought it´s a bad idea.
It makes my work better organized.
Good Luck
nelsonpaixao@yahoo.com.br
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
