you will get this information from sys.databases view. and criteria you are looking is more related to recovery model. you can use recovery_model = 1 for your scenario.

try to execute setspn -L and find out if you have any invalid spn;s in the active directory. get those deleted and it shoud work fine..

The default trace files generally store information related to configuration options. it will not store any thing related to DML activities.

generally, if the table is having column with default value...

on clusters, generally you need local admin right for SQL Server to run properly. But if you dont want to give sqlserveragents local admin rights, think of creating local group...

use setspn -L at command prompt and see, if there is invalid SPN in active directory. Open a service call to active directory group to delete the invalid...

you can build the synamic queries using osql utility to achieve the task.

You can choose from the following:

either SQL Profiler Trace or you can use some third party tools lke logexplorer or LogPI etc. Or you can change you C2 Audit level...

You can check the following sql also which tells about the backups.

SELECT  B.NAME, ISNULL(STR(ABS(DATEDIFF(DAY, GETDATE(),

 MAX(BACKUP_FINISH_DATE)))), 'NEVER') 'DAYS - THE BACKUP IS DONE' ,

 ISNULL(CONVERT(CHAR(10), MAX(BACKUP_FINISH_DATE), 101), 'NEVER') 'DATE- ON WHICH...

http://support.microsoft.com/?scid=kb;en-us;231619&spid=2852&sid=1055

For configuring SQL Mail, refer to the following link:

http://support.microsoft.com/kb/263556/

for Common SQL Mail Problems refer to

http://support.microsoft.com/kb/315886/

For DTS mails refer to:

http://www.sqldts.com/default.aspx?287

Thanks

you can use FTP. Its works with UNIX and Windows environment.

what you can do is give that user a right to execute sp_start_job stored procedure.

You can either try "C2 Audit" for the server or server side traces.

May be you system admins have implemented some software to apply Group policies on the server level. These errors belong to that.

your database can go in suspect mode if

1. there is power outage

2. the drive on which your log file or data file is placed, it is full

3. some missing files...