Don't even try it. It would be very unwise to do that in a trigger because of multi-user considerations and because the data in the file would be inaccurate anyway. Remember that a trigger sees uncommitted data but it would be hard to roll back changes to a file. Also, you will very likely create an undetectable deadlock and halt your system.
Please explain A) Why you need this data in a text file, and B) how often the file needs to be updated.
If you want updates in real time then it would be better to change whatever process consumes the data so that it reads the table instead of the file. If you want an audit trail then take a look at the Change Data Capture feature in SQL Server 2008.
Well we are working with Audit database and every time someone deletes it or updates the record or inserts a record trigger will fire and store all info in a seprate table, but the size of database is growing very fast as insert update and delete are going every second we r new to SQL server.,...... so can we write records to text file or what will be the best strategy i have no idea how to come up with strategy
Writing to a text file is not the solution. It's not likely to save you much space anyway.
I'd concentrate on trying to optimise the existing audit process. Look at what is consuming the space and maybe be more selective about the data you capture. If you are using SQL Server 2008 Enterprise then consider using the Change Data Capture feature instead of triggers.
Well we are working with Audit database and every time someone deletes it or updates the record or inserts a record trigger will fire and store all info in a seprate table, but the size of database is growing very fast
So get more drive space or start archiving old data.
Writing to a text file with a trigger is a bad idea.
If it's not practically useful, then it's practically useless.