local variable assignment in CREATE TRIGGER

Hi Guys,

i'm batttling with the below Trigger creation

__________________________________________________ _
CREATE TRIGGER dbo.Fochini_Insert ON dbo.FochiniTable AFTER INSERT AS
BEGIN
DECLARE @.v_object_key VARCHAR(80)
DECLARE @.v_object_name VARCHAR(40)
DECLARE @.v_object_verb VARCHAR(40)
DECLARE @.v_datetime DATETIME

SELECT ins.Cust_Id INTO @.v_object_key FROM inserted ins <-- my problem area!!
SET @.v_object_name = 'FochiniTable'
SET @.v_object_verb = 'Create'
SET @.v_datetime = GETDATE()

IF ( USER <> 'webuser' )
INSERT INTO dbo.xworlds_events (connector_id, object_key, object_name, object_verb, event_priority, event_time, event_status, event_comment)
VALUES ('Fochini', @.v_object_key, @.v_object_name, @.v_object_verb, '1', @.v_datetime,'0', 'Triggered by Customer CREATE')

END
________________________________________________

i'm trying to get the INSERTED variable from table FochiniTable on colomn Cust_Id

and the statement: SELECT ins.Cust_Id INTO @.v_object_key FROM inserted ins - is failing [still a newbie on mssql server 2000]

any help will be appreciated
lehare.solved by modifying the errored line with

SELECT @.v_object_key = ins.Cust_Id FROM inserted ins

thanx any wayz

Local user XP -> remote XP

HI Guys,
Got the following scenario:
Client machine: Windows XP Pro (SP2), logged in as local user
Server machine: Windows XP Pro (SP2), running SQL Server 2000
both machines in same Domain.
I am attempting to connect from the client to the server using SQL
Server authentication, which is definitely enabled as an option on the
remote machine. SQL Client Network lists TCP/IP and Named Pipes
enabled, with TCP/IP highest. Neither connecting through TCP/IP nor
name pipes (using isql) succeeds, and I get a generic "SQL Server does
not exist" type message through query analyzer.
This started with a problem running an ASP.NET website against a remote
database, but I've verified I can 1) Connect to the server using
Windows Authentication, when I'm logged in as a domain user, 2) Connect
using the SQL Server credentials, when I'm logged in as a domain user.
I wouldn't be surprised for NP to fail when I'm a local user, but
TCP/IP shouldn't be affected by who's logged in, should it?
Okay, normal bits now of "this used to work, and I'm sure I haven't
changed anything". Only thing I have done recently was install the
latest MS updates as delivered through Automatic Updates. I'm not sure
if anything has changed on the server, since it's another devs
development machine, but I wouldn't expect him to have been "playing"
in this area.
I was initially unconcerned by this problem, since our live webserver
talks directly to a local instance of SQL, so all should be well. Until
I remembered that as part of the next rollout, we plan to move the
databases onto a separate box. So I'd like to understand this problem
in the development area in case it happens on live as well.
Sorry for rambling on. And I've probably forgotten something important
too. Thanks in advance for any help.
DamienHi,
I guess secuzrity is blocking your request on the other machine. YOu
have to open the ports of SQL Server on the hosting machine that the
client can connect to an instance. The default port of SQL Server is
1433, but that can be different on your machine if you changed another
one on installation time. For more information about Windows XP SP2 and
SQL Server read the following article.
http://support.microsoft.com/defaul...kb;en-us;841249
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--|||Jens wrote:
> Hi,
> I guess secuzrity is blocking your request on the other machine. YOu
> have to open the ports of SQL Server on the hosting machine that the
> client can connect to an instance. The default port of SQL Server is
> 1433, but that can be different on your machine if you changed another
> one on installation time. For more information about Windows XP SP2 and
> SQL Server read the following article.
> http://support.microsoft.com/defaul...kb;en-us;841249
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
Doh! The thing I forgot to do was... Check that TCP connections worked
directly. Turned out that all my previous succesful connections were NP
connections. So I'll be looking at the firewall then...
Cheers,
Damien