There are three types of triggers:
Form level
Block level 
Item level
If you want to validate the values of an Item, usually use 
Item level trigger, such as POST-CHANGE trigger.

Crystal Reports is a powerful, dynamic, actionable 
reporting solution that helps you design, explore, 
visualize, and deliver reports via the web or embedded or 
stand alonein enterprise applications. It enables end users 
to consume reports with stunning visualizations, conduct on-
report business modeling, and execute decisions instantly 
from the report itself—reducing dependency on IT and 
developers.
we cant also Export data from crystal reports to excel,.CVS 
files


There are four major components in crystal reports Report 
designer, Reports engine, Report viewer and object models.
Report designer gives a graphical interface to create and 
modify reports. To view the designer add a new crystal 
report file and double click on it you should see the 
report designer 
 
it is mainly used in Vb,.net with sql or oracle .

www.allinterview.com

http://blog.sqlauthority.com

1.SQL Server 2005 has better tool enhancements like SQL 
Server Management Studio.
2.Developers can write Native .NET Stored Procedures and 
deploy them to SQL Server 2005. 
3.It has more Enhancements in the areas of DBA, Developer 
Productivity with .NET 

For More details..Verify these links..
http://wiki.answers.com/Q/Diff_between_sql_server_2000_and_s
ql_server_2005
http://techinterviewquestion.blogspot.com/2008/06/some-
difference-between-sql-server-2000.html

What are the Differences Between SQL Server 2000 and SQL Server 2005?
I've been asked this question every time that there's a new
version and yet I've never been able to give what I think is a
nice, concise, logical answer that satisfies the asker. Probably
it's a lack of my ability to easily form words in my mouth and
get them out in the proper order, so I decided it might make some
sense to do this on paper (metaphorically speaking) and help
others out.

Like many of you, I usually get this question from someone
outside of SQL Server. A windows admin, a network guy, etc.,
someone who has little contact with SQL Server. Or maybe it's
someone who's been stuck with admin'ing a SQL Server instance.

In any case, I wanted to try and explain this concisely for the
non-DBAs. As I began this project, however I soon realized that
it's not easy to just give a good general answer. As with
everything else in SQL Server it seems that "it depends" is the
best general answer, so I broke this up into a few areas. This
part will look at the administrative differences and the next
will cover more of the development differences.

The Administrative Differences
Administering a SQL Server instance to me means making sure the
server service runs efficiently and is stable and allows clients
to access the data. The instance should keep data intact and
function according to the rules of the code implemented while
being well maintained.

Or for the non-DBAs, it means that you are the sysadmin and it
just works.

The overall differences are few. Sure we use Management Studio
instead of Enterprise Manager, but that's not really a big deal.
Really many of the changes, like being able to change connections
for a query, are superficial improvements that don't really
present a substantial change. If you think they do, you might be
in the wrong job.

Security is one area that is a very nice improvement. The
separation of the schema from the owner makes administrative
changes easier, but that is a big deal because it greatly
increases the chances you won't keep an old account active
because it's a pain to change owners on objects. There's also
more granularity and ease of administration using the schema as
another level of assigning permissions.

Another big security change is the ability to secure your web
services using certificates instead of requiring authentication
using a name and password. Add to that the capability to encrypt
data, and manage the keys, can make a big difference in the
overall security of your data. You have to carefully ensure your
application and access is properly secured, but just the
marketing value of encryption when you have credit card,
financial, or medical data is huge. SQL Server 2000 had no real
security features for data, allowing an administrator to see all
data. You could purchase a third party add-on, but it was
expensive and required staff training. Not that you don't need to
learn about SQL Server 2005, but it should be a skill that most
DBAs will learn and be able to bring to your organization over time.

High availability is becoming more and more important to all
sizes of businesses. In the past, clustering or log shipping were
your main choices, but both were expensive and required the
Enterprise Edition. This put these features out of the reach of
many companies, or at least, out of many DBAs' budgets. With SQL
Server 2005, you can now implement clustering, log shipping, or
the new Database Mirroring with the Standard edition. With the
ability of Database Mirroring to use commodity hardware, even
disparate hardware between the primary and mirror databases, this
is a very reasonable cost solution for almost any enterprise.

There are also online indexes, online restores, and fast recovery
in the Enterprise Edition that can help ensure that you take less
downtime. Fast recovery especially can be an important feature,
allowing the database to be accessed as the undo operations
start. With a log of open transactions when a database is
restarted, this can really add up to significant amounts of time.
In SQL Server 2000, you had to have a complete, intact database
before anyone could access it. With redo/undo operations
sometimes taking a significant amount of time, this could delay
the time from Windows startup to database availability by minutes.

Data sizes always grow and for most companies, performance is
always an issue on some server. With SQL Server 2000, you were
limited to using 2GB of RAM and 4 CPUs on the Standard Edition.
The number of CPUs hasn't changed, but you can now use as much
RAM as the OS allows. There also is no limit to the database
size, not that the 1,048,516 TB in SQL Server 2000. Since RAM is
usually a limiting factor in the performance of many databases,
upgrading to SQL Server 2005 could be something you can take
advantage of. SQL Server 2005 also has more options and
capabilities on the 64-bit platform than SQL Server 2000.

Why Upgrade?
This is an interesting question and one I've been asked quite a
bit over the last 18 months since SQL Server 2005 has been
released. The short answer is that if SQL Server 2000 meets your
needs, then there's no reason to upgrade. SQL Server 2000 is a
strong, stable platform that has worked well for millions of
installations. If it meets your needs, you are not running up
against the limits of the platform, and you are happy with your
system, then don't upgrade.

However, there is a caveat to this. First the support timeline
for SQL Server 2000 shows mainstream support ending next year, in
April 2008. I can't imagine that Microsoft wouldn't extend that
given the large number of installations of SQL Server 2000, but
with the next version of SQL Server likely to come out next year,
I can see this being the point at which you cannot call for
regular support. The extended support timeline continues through
2013, but that's an expensive option.

The other consideration is that with a new version coming out
next year, you might want to just start making plans to upgrade
to that version even if you're happy with SQL Server 2000. If the
plan is to release a new version every 2-3 years, you'll need to
upgrade at least every 5-6 years to maintain support options.

Be sure that in any case you are sure the application you are
upgrading, if it's a third party, is supported on SQL Server 2005.

Lastly, if you have multiple servers and are considering new
hardware for more than 1 of them, it might make some sense to be
sure to look at buying one large 64-bit server and performing
some consolidations. I might recommend that you wait for the next
version of SQL Server if you are worried about conflicts as I
have heard rumors of switches to help govern the resource usage
in Katmai (SQL Server 2008).

A quick summary of the differences:

Feature	SQL Server 2000	SQL Server 2005
Security	Owner = Schema, hard to remove old users at times	Schema
is separate. Better granularity in easily controlling security.
Logins can be authenticated by certificates.
Encryption	No options built in, expensive third party options
with proprietary skills required to implement properly.
Encryption and key management build in.
High Availability	Clustering or Log Shipping require Enterprise
Edition. Expensive hardware.	Clustering, Database Mirroring or
Log Shipping available in Standard Edition. Database Mirroring
can use cheap hardware.
Scalability	Limited to 2GB, 4CPUs in Standard Edition. Limited
64-bit support.	4 CPU, no RAM limit in Standard Edition. More
64-bit options offer chances for consolidation.
Conclusion
These seem to be the major highlights from my perspective as an
administrator. While there are other improvements, such as the
schema changes flowing through replication, I'm not sure that
they represent compelling changes for the non-DBA.

In the next article, I'll examine some of the changes from a
developer perspective and see if any of those give you a reason
to upgrade.

And I welcome your comments and thoughts on this as well. Perhaps
there are some features I've missed in my short summary.

select max(sal),ename from emp where sal=(select max(sal) 
from emp) group by ename;

select sal,ename from emp where sal=(select max(sal) from 
emp);

SELECT ename,MAX(sal) 
  FROM EMP
  GROUP BY ename;

select ename,sal from emp where sal=(select max(sal) from emp);

select ename from emp where sal=(select max(sal) from emp);
      ENAME
     ---------
      KING
    
  --first execute the inner query like
    select max(sal) from emp;
    MAX(SAL)
    ---------
     5000
   --- after that salary value pass the outer query like   
     this
    select ename from emp where sal=5000
      ENAME
     ---------
      KING
  
      Email:thota.madhav@gmail.com

select ename , max(sal) 
from emp 
group by ename ;

to retrieve data from the database tables is called query

A Query is a SELECT statement, which is always successful.

in char it allocates the memory space as static where as in 
varchar2 it allocates the memory space as dynamic


OR

char is a space mapping function where as in varchar2 it is 
not mapping the space it occupies the exact size of the 
string

Have more diff between char and varchar2

char size only 2000 bytes in sql, default size is 1 byte.
it will occupying the trailing spaces. so much of memory wasted.

varchar2 size 4000 bytes in sql and no default size.
it will not occupying the trailing spaces.

Partitioning option by Oracle version
Partitioning seems like something Oracle should have been 
able to do since day one, but interestingly enough, Oracle8 
was its introduction.

Oracle Version
 Feature
 
8
 Range
 
8i
 Hash and Composite Range-Hash
 
9i
 List
 
10g
 Enhanced features, fast split, IOT, indexes
 

Partition operations were admittedly difficult (an 
iLearning video even says so) in earlier versions, and this 
difficulty – especially in maintenance operations - made 
many users leery of implementing this feature.

Table partition options are straightforward, and five of 
them are: range, list, hash, composite range-hash, and 
composite range-list. Options for index-organized tables 
include range, list and hash. Partitioned indexes don’t 
seem to get nearly as much attention as partitioned tables, 
and a lack of understanding how the index options differ 
can lead to significant pitfalls.

Partitioned Indexes
You have three choices when it comes to indexes: local, 
global partitioned, and global non-partitioned. A local 
index maps one-to-one with the partitions of the table. A 
global partitioned index can be based on a different key 
and even have a different number of partitions. A global 
non-partitioned index is essentially one big index on the 
partitioned table. The diagram below illustrates the 
differences (table partitions are the shaded boxes, indexes 
are the curly braces).



Problem areas
Where do the pitfalls arise? Two seemingly simple 
operations can blow away an index and leave your 
partitioned table in a state of disrepair. There won’t be 
any data loss, but if an application is dependent on having 
an index, the loss of that index can bring a session to its 
knees, that is, what was a .01 seconds lookup can now take 
40 minutes. On an OLTP-type database, you’re dead in the 
water.

The global non-partitioned (GNP) index is the index of 
interest for the pitfall examples. Think of the GNP index 
as a map of data, and you should, because that is exactly 
what it is. What happens when a hole is punched in the 
middle of the map? In this case, index “data” is lost, so 
without knowing the complete structure of the index, Oracle 
declares the index to be unusable, and there goes your 
performance out the window. From personal experience, 
rebuilding a 250 million plus records index took almost six 
hours. A partition, and a very small one at that, needed to 
be repopulated with data, and there were two choices to 
clean out the questionable data: simply delete and commit, 
or truncate the partition. The global index contained the 
index for the primary key, and the operation to clear the 
data blew the index, so to speak.

Truncate a partition
How do you truncate a table partition? Does “truncate table 
X partition Y” work? Actually, the syntax involves “alter 
table truncate partition.” The key part of the alter table 
statement is to include two or three words (depending on 
the type of table and index), and those words are “update 
<global> indexes.” 

Buried in the Administrator’s Guide, applying what is 
stated in the sentence below means the difference between 
something routine and something potentially expensive (loss 
of up time, failure to meet an SLA, slow down on a 
production line, and so on).

Unless you specify UPDATE INDEXES, any global indexes are 
marked UNUSABLE and must be rebuilt.

Personally, I think this statement should be highlighted 
much better than it currently is, or placed in an indented 
note or warning/caution statement. 

How can you wind up in a situation where a global non-
partitioned index is related to a partitioned table? 
Actually, it is quite easy to create this situation. 
Partition a table by one key or value, and then create an 
index on another attribute. An example would be a partition 
key based on a list (states, departments, subassemblies, 
etc.) and then base the primary key on, say, a part number. 
Recall that when creating a primary key (and what other 
constraint?) you get an index for free. You now have a 
global non-partitioned index on a partitioned table. 

Splitting a partition
The same blown index problem can occur when splitting a 
partition. At least here, the documentation does a better 
job of pointing out what happens and how you can prevent it 
from occurring in the first place.



This example splits a partition (what type of partitioning 
is being used here?) and keeps global indexes intact.

alter table coupons
split partition p4_coupons values ('415')
into (partition p415, partition p4_coupons)
update global indexes;

Adding “update global indexes” to either operation 
(truncation and splitting) makes all the difference in the 
world.

Breaking an index
How do you know what type of index is being used? If you’re 
using TOAD, a partitioned index sticks out because of an 
icon. If you’re in SQL*Plus, then you have to be a bit more 
clever to determine the partition type. Let’s take a look 
at the SH sample schema via TOAD. Shown below are the 
indexes for the SALES table.



The data is eligible to be contained in 28 partitions, and 
the partition key is TIME_ID. Not all partitions have 
records in them, and we’re going to create that situation 
in one other partition by truncating it. To help illustrate 
the global non-partitioned index example, we’ll create a 
pseudo primary key based on a sequence, and then take 
another look at the indexes.



Refresh the list of indexes in TOAD and now the free index 
named PK_SALES_ID appears.



Let’s pick SALES_Q2_1998 as the guinea pig. You can copy 
the data off into a backup table first if you want to have 
the SH schema intact afterwards. The picture below shows 
both steps – copying the data and truncating the partition.



Now that the partition named SALES_Q2_1998 has been 
truncated, what is the state of our indexes? Refresh the 
list of indexes in TOAD to see the result.



Red X’s in TOAD are symbols you generally do not want to 
see, as they represent something that is broken or invalid. 
To fix the index, we have to rebuild it. We can do that 
through TOAD or via the command line (and TOAD will show 
you the SQL syntax if so desired).





Again, refresh the list of indexes in TOAD and the 
PK_SALES_ID index is now in a good state. Let’s truncate 
another partition, but this time add the update indexes 
clause. But first, just for grins, what happens if we 
truncate an empty partition and do not use the update 
indexes clause? Hopefully nothing happens as no index 
information (because of its associated data) was lost, and 
you can test the veracity of that statement for yourself.

SQL> create table sales_q3_1998 as
  2  select * from sales partition (sales_q3_1998);

Table created.

SQL> alter table sales truncate partition sales_q3_1998
  2  update global indexes;

Table truncated.

SQL> select object_name from user_objects
  2  where status = 'INVALID'
  3  and object_type = 'INDEX';

no rows selected

The results indicate that the partition was truncated and 
that no indexes were marked as unusable (or have a status 
of INVALID). The same types of examples using a SPLIT 
operation are easily demonstrated using the same procedures 
as what we did for the truncate partition operation.

when we try to dml operation on orginal table in trigger.
then the trigger was excuted but while perfoming any action
on original table it will show mutating..

to overcome the above problem we need to create a autonamous
trasaction trigger..

Implicit cursors:  SQL%ISOPEN always returns FALSE, 
indicating that the implicit cursor has been closed.

I hope below example gives you very fair idea.

SQL> BEGIN
  2     UPDATE employee
  3        SET salary = salary *2
  4     WHERE id = '01';
  5
  6  IF not SQL%ISOPEN THEN
  7       DBMS_OUTPUT.PUT_LINE('closed');
  8  END IF;
  9  END;
 10  /
closed

PL/SQL procedure successfully completed.

Thanks
-Pr@$@d

sure..

In a Report of more than 1 page information. Then BETWEEN
PAGES trigger fire when one move from one page to other
page. In this trigger we can write process which is required
to affect other page values.