Defining Variables in Date fields within a Trigger?

Hi All,

I am creating an Insert Trigger with following example of code for you to go off(just an example)

DECLARE @.CREATIONDATE VARCHAR(12)
SET @.CREATIONDATE = (Select Inserted.Creation_Date from Inserted)

Insert into fintest.dbo.glf_chart_acct(fintest.dbo.chart_name, fintest.dbo.accnbri, fintest.dbo.descr1, fintest.dbo.date)
Values ('Name', 'Code', 'Description', {d @.CREATIONDATE})

Inserted.CreationDate is Varchar and the fintest.dbo.date colunm is a datetime field

When checking the Syntax for the trigger it errors saying that - 'Error Syntax near '@.CREATIONDATE'

It works fine if I just insert a static value such as
{d '2002-10-10'}. Am I able to replace the static value with a variable and if so what will my syntax be? How would it look?

Thanks
Anthonyhow about:

Insert into fintest.dbo.glf_chart_acct
(chart_name, accnbri, descr1, date)
select 'Name', 'Code', 'Description', Creation_Date
from Inserted

SQL Server will automatically convert a string to a date and you have the advantage of handeling one or more records at a time!|||DECLARE @.CREATIONDATE VARCHAR(12)
SET @.CREATIONDATE = (Select Inserted.Creation_Date from Inserted)

Insert into fintest.dbo.glf_chart_acct(fintest.dbo.chart_name, fintest.dbo.accnbri, fintest.dbo.descr1, fintest.dbo.date)
Values ('Name', 'Code', 'Description', {d @.CREATIONDATE})

Inserted.CreationDate is Varchar and the fintest.dbo.date colunm is a datetime field

How about instead of the {d @.CREATIONDATE} you either put just @.CREATIONDATE or try a CAST(@.CREATIONDATE as datetime)

Defining connections as private variables

Is there any harm in defining a SqlConnection as a private class variable for a web page?

Private SqlConnection cn = new SqlConnectection(ConfigurationManager.ConnectionStrings["MyString"].ConectionString);

The connection is only opened in certain event handlers, and is closed right after use. It was always my understanding that creating the connection is not a big deal but opening the connection is.

Is that correct?I would declare the connection variables in the method that uses them. What happens when Method1 calls Method2 and both use that connection variable? Declaring them in as small a scope as possible makes lots more sense.