IF .....
   INSERT #Tbl (Fields)
   EXEC usp_SelectProc1 @Arg1, Arg2...Argn
ELSE
   INSERT #Tbl (Fields)
   EXEC usp_SelectProc2 @Arg1, Arg2...Argn

• You need good documentation/comments otherwise the dependencies can be hard to keep track of.


• Always use field lists in your INSERT statements just incase the exec usp_SelectProc is altered to returb additional fields.

quote:

---

I take it that you are talking about a web application?
[{quote]

GUI is displayed in Browser

quote:

---

I have found that tasks that are too small to affect the performance of normal apps become massive overheads on web apps simply because of the amount of traffic a big site can have.

---

No issue, because at the moment it is an internal app with a VERY limited number of user. It might be opened to affiliated companies in the future, but even then there are only about <50 regular users.

quote:

---

To give an example, my company stress tested one of our sites with varying numbers of simultaneous connections. The site was vastly more successful than was anticipated and we had to strip out some of the error reporting from our stored procedures in order to maintain performance. Under normal conditions this would have had no measurable affect, but with the sheer volumes of users it became an issue.

---

Just out of interest. About how many users do you speak?

[quote]
I would tend to put input validation in the client front end and in a middle tier on the web server probably enclosed within a DLL.

Validation of parameters (for web apps), once they have reached your database server should be kept as simple and as light weight as possible.

---

quote:

---

What you could do is write your GUI so that your main user interface is in a bald HTML file and that file is called in the context of your page furniture.

If someone else wants to write their own GUI they can do it but they are limited to specifying the stylesheet and page furniture.

---