What are the difference between a PROCEDURE & FUNCTION ?

What is difference between a PROCEDURE & FUNCTION ?

1. Function is mainly used in the case where it must return a value. Where as a procedure may or may not return a value or may return more than one value using the OUT parameter.

2. Function can be called from SQL where as procedure can not be called from the sql statements
3. Functions are normally used for computations where as procedures are normally used for executing business logic.

4. You can have DML (insert,update, delete) statements in a function. But, you cannot call such a function in SQL.

5. Function returns 1 value only. Procedure can return multiple values (max 1024).

6.Stored Procedure: supports deferred name resolution. Example while writing a procedure that uses table named tabl1 and tabl2 etc..but actually not exists in database is allowed only in during creation but runtime throws error Function wont support deferred name resolution.

7.Stored procedure returns always int by default zero. where as function return type could be scalar or table or table values

8. Stored procedure is precompiled execution plan where as functions are not.

9.A procedure may modify an object where a function can only return a value The RETURN statement immediately completes the execution of a subprogram and returns control to the caller.

Call Me

US June 2008 Visa Bulletin

Fam-ily	All Other Areas Except Those Listed	CHINA born	INDIA	MEXICO	PHILIP
1st	15MAR02	15MAR02	15MAR02	22JUL92	15MAR93
2A	15JUL03	15JUL03	15JUL03	01MAY02	15JUL03
2B	01AUG99	01AUG99	01AUG99	08APR92	22FEB97
3rd	08JUN00	08JUN00	08JUN00	01AUG92	01APR91
4th	22AUG97	01FEB97	01FEB97	15DEC94	08MAR86

	All Other Areas Except Those Listed	CHINA- mainland born	INDIA	MEXICO	PHILIPP.
Employmnt Based
1st	C	C	C	C	C
2nd	C	01APR04	01APR04	C	C
3rd	01MAR06	22MAR03	01NOV01	01JUL02	01MAR06
Other Workers	01JAN03	01JAN03	01JAN03	01JAN03	01JAN03
4th	C	C	C	C	C
Certain Religious Workers	C	C	C	C	C
5th	C	C	C	C	C
Targeted Employ-ment Areas/ Regional Centers	C	C	C	C	C

Gopalkrishna Gandhi

An excellent piece from Urvish Kothari ( yet again).. I heard a lot about this great personality - Gopalkrishna Gandhi - when he rejected the offer to become Chancellor of Gujarat Vidhyapith, but this shows an extra-ordinary and superb personality in him ..

Struts 1.x Vs. Struts 2.x

Feature	Struts 1	Struts 2
Action classes	Struts 1 requires Action classes to extend an abstract base class. A common problem in Struts 1 is programming to abstract classes instead of interfaces.	An Struts 2 Action may implement an Action interface, along with other interfaces to enable optional and custom services. Struts 2 provides a base ActionSupport class to implement commonly used interfaces. Albeit, the Action interface is not required. Any POJO object with a execute signature can be used as an Struts 2 Action object.
Threading Model	Struts 1 Actions are singletons and must be thread-safe since there will only be one instance of a class to handle all requests for that Action. The singleton strategy places restrictions on what can be done with Struts 1 Actions and requires extra care to develop. Action resources must be thread-safe or synchronized.	Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues. (In practice, servlet containers generate many throw-away objects per request, and one more object does not impose a performance penalty or impact garbage collection.)
Servlet Dependency	Struts 1 Actions have dependencies on the servlet API since the HttpServletRequest and HttpServletResponse is passed to the execute method when an Action is invoked.	Struts 2 Actions are not coupled to a container. Most often the servlet contexts are represented as simple Maps, allowing Actions to be tested in isolation. Struts 2 Actions can still access the original request and response, if required. However, other architectural elements reduce or eliminate the need to access the HttpServetRequest or HttpServletResponse directly.
Testability	A major hurdle to testing Struts 1 Actions is that the execute method exposes the Servlet API. A third-party extension, Struts TestCase, offers a set of mock object for Struts 1.	Struts 2 Actions can be tested by instantiating the Action, setting properties, and invoking methods. Dependency Injection support also makes testing simpler.
Harvesting Input	Struts 1 uses an ActionForm object to capture input. Like Actions, all ActionForms must extend a base class. Since other JavaBeans cannot be used as ActionForms, developers often create redundant classes to capture input. DynaBeans can used as an alternative to creating conventional ActionForm classes, but, here too, developers may be redescribing existing JavaBeans.	Struts 2 uses Action properties as input properties, eliminating the need for a second input object. Input properties may be rich object types which may have their own properties. The Action properties can be accessed from the web page via the taglibs. Struts 2 also supports the ActionForm pattern, as well as POJO form objects and POJO Actions. Rich object types, including business or domain objects, can be used as input/output objects. The ModelDriven feature simplifies taglb references to POJO input objects.
Expression Language	Struts 1 integrates with JSTL, so it uses the JSTL EL. The EL has basic object graph traversal, but relatively weak collection and indexed property support.	Struts 2 can use JSTL, but the framework also supports a more powerful and flexible expression language called "Object Graph Notation Language" (OGNL).
Binding values into views	Struts 1 uses the standard JSP mechanism for binding objects into the page context for access.	Struts 2 uses a "ValueStack" technology so that the taglibs can access values without coupling your view to the object type it is rendering. The ValueStack strategy allows reuse of views across a range of types which may have the same property name but different property types.
Type Conversion	Struts 1 ActionForm properties are usually all Strings. Struts 1 uses Commons-Beanutils for type conversion. Converters are per-class, and not configurable per instance.	Struts 2 uses OGNL for type conversion. The framework includes converters for basic and common object types and primitives.
Validation	Struts 1 supports manual validation via a validate method on the ActionForm, or through an extension to the Commons Validator. Classes can have different validation contexts for the same class, but cannot chain to validations on sub-objects.	Struts 2 supports manual validation via the validate method and the XWork Validation framework. The Xwork Validation Framework supports chaining validation into sub-properties using the validations defined for the properties class type and the validation context.
Control Of Action Execution	Struts 1 supports separate Request Processors (lifecycles) for each module, but all the Actions in the module must share the same lifecycle.	Struts 2 supports creating different lifecycles on a per Action basis via Interceptor Stacks. Custom stacks can be created and used with different Actions, as needed.

Gunvant Shah's Paghadino Wal (!)

This is an excellent though provoking short yet superb.. yet again from Gunvant Shah.. I am sure, one will enjoy this.

Computer keyboards can be dirtier than a toilet

Fri May 2, 12:30 AM ET

CANBERRA (Reuters Life!) - Think twice before eating those dropped crumbs off your computer keyboard -- you might as well be eating off a toilet seat, according to a new study on the amount of germs on keyboards.

A study by British consumer magazine "Which? Computing" asked a microbiologist to examine 33 keyboards in a typical London office, a toilet seat and a toilet door handle, for bugs generally found in unhygienic places.

Four keyboards were judged potential health hazards and the microbiologist recommended the removal of one keyboard as it had 150 times the pass limit of bacteria -- five times filthier than the swabbed toilet seat.

"Most people don't give much thought to the grime that builds up on their PC, but if you don't clean your computer, you might as well eat your lunch off the toilet," said Sarah Kidner, editor of "Which? Computing" in a statement.

The study found that eating lunch at desks is the main cause of a bug-infested keyboard. Dropped crumbs and food encourages the growth of millions of bacteria.

Poor personal hygiene, such as not washing hands after going to the toilet, may also add to the dirtiness of keyboards.

But despite the health hazard of a dirty keyboard, a survey of 4,000 people by the magazine found one in 10 people -- or 11 percent -- never cleaned their keyboard while another two in 10 never cleaned their mouse.

Almost half -- or 46 per cent -- cleaned their keyboard less than once a month.

To clear out bugs, the magazine recommends users unplug keyboards, turn them upside down and shake them.

(Reporting by Belinda Goldsmith, Editing by Gillian Murdoch)