Not exactly.

The execution comes later in another proc.

HOWEVER the printing of the variable is just BEFORE I set the variable value to the DB. What is printed to screen is absolutely correct. What is saved to the DB is truncated. I know this not from just a print but doing a LEN(PreparedStatement) wihtin a select query.

I have a work around that I am implementing as we speak. This so far seems to work but I don't particularly like it. It does add some visibility to each step of my process; and has no significant impact on performance. That said I still do not like it and I will continue to dig.

The work around, in case anyone else runs into this is as follows.

My statement is built through the process of running several procs. One builds the insert / select. The Select get s set with aliases for the FK's in the table.

Another proc then builds the JOIN statement and yet a third builds the WHERE clause.

I am sorry but I can not go into the business rules behind this or why all of this is dynamic.

Anyway the work around is each of these steps. Rather than taking the value of the column and ADDING to it is not saved in its own column.

The proc that does the execution; rather than loading the contents of the one column will not concatenate each of said columns. The JOIN and WHERE columns I use a coalesce with my alternate value as a space, for those tables that do not have one or both of those conditions in their respective statements.

I just made my changes and outside my process read each of these into a variable and it worked fine.

Again not what I WANT but it works and allows me to move forward so it will do for the moment.

Thank you all for your efforts and contribution. When I I figure out the root cause of this I will share with the community.