SQL_Variant

CodingAngelCodingAngel Posts: 6
edited January 3, 2006 12:12PM in SQL Data Compare Previous Versions
Hi folks.

I just found out, that DTS does not support transferring sql_variant fields,
which we are using for audit trail generation.

As sql_variant is not supported by ODBC the data stored in that fields
is completely destroyed after transferring tables with DTS.

As our company just bought the Red-Gate Tools I just started to compare
the data with the SQL-Data Compare tool. being totaly convinced that
the Red-Gate tool will be able to solve that problem, but to my
big disappointment, it ended with the same result.
The synchronisation script runs through and immediately afterwards
the tool shows exactly those sql_variant fields as being different...
which they also really are... :cry:

So now the big questions:
Are you going to fix this ?
(If it is possible, because, just let me guess, you are also using ODBC connections?)

If so, when will that be available?

And finally: Has never ever anybody else had that problem?

Greetings from Germany!
· Share on Twitter

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hello,

    Sorry for the delay. I'm afraid I don't have a straight answer, but I can promise we'll look into it. SQL Data Compare uses ADO .NET rather than ODBC, if that information helps any. As far as I know, Data Compare should be comparing the actual bytes of sql_variants.
    · Share on Twitter
  • CodingAngelCodingAngel Posts: 6
    Well, it does compare them,
    but the tool does not succeed in generating correct scripts to update
    the data on the new server...
    · Share on Twitter
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    I would imagine then that SQL Data Compare is scripting the data as either a quoted string, number, or bytes in the case of an image column. I can't see how this would cause a problem, though.
    · Share on Twitter
This discussion has been closed.