Is it possible?

I'm putting this into 1 lookup:

INSERT INTO tblOrganization (iOrganizationId,sIntegrationCode,
iOrganizationTypeId,sName,sNameLegal,sCustomFieldS tring1,
srtCustomFieldSmallInt1,sABCLicense,sPhone,iOrgani zationStatusId)
values (
?,
dbo.padstring(?,6),
?,
dbo.initcap(?),
dbo.initcap(?),
?,
dbo.convertCharToNum(?),
dbo.padstring(?,12),
?,
?)

which crashes the Enterprise Manager every time I try to run it. After
removing it to no funcitons and just straight ?s it all ran fine. It
doesn't even mind the function that has a single ?. Where it freaks
out and crashes is if i put in even a single one of the functions that
pass the ? and a constant. Is it possible to call those from within a
lookup (do I just need to up the sevice pack or something) or am I
pretty much dead in the water here? ::all on SQL Server 2000::

Hello Jayyde,.

What could be happening here is that the design time is getting itself in
a twist, I would be very tempted to do something like this

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


i.e. build the statement in an Active Script task and then populate the SQLStatement
property at runtime.


This is an ExecuteSQL task right?




Allan Mitchell
www.SQLDTS.com
www.SQLIS.com
www.Konesans.com

It's going to be in a DDQ Task. Basic senario is we have data coming
in from 1 table on an AS400, 1 staging table already made where the
massive transformations are, then I need to go from that table and
split the data into 4 different tables (with inserts, updates, and
deletes on all 4). Now unfortunately mutliple jury-rigged lookups is
the easiest way we can figure to do them. This 1st one is an insert
into 1 of the 4 tables (obviously ). There will be a main Ax script
where we'll tell the DDQ which lookup to run and where the 10 different
?s are coming from. It seems to be ok with that until I want to do
something like pad the string (which simple passes a number and pads
the thing with 0s til it reaches the length that is also passed in the
function). That's the only thing that it freaks out on.