When I try and import a sql 2005 database using the adoUnicode driver, I receive the following error:

ElevateDB error #202 An error occured with the module edbmigrateado ([Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name 'CHECK_CONSTRAINTS')

Has anyone tried importing a sql 2005 database? Will it work.

Regards,

David

David,

<< When I try and import a sql 2005 database using the adoUnicode driver, I
receive the following error:

ElevateDB error #202 An error occured with the module edbmigrateado
([Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name
'CHECK_CONSTRAINTS') >>

I'm checking this out right now and will let you know what I find.

--
Tim Young
Elevate Software
www.elevatesoft.com

David,

Okay, I just tried it and it worked fine here using the native SQL client
ODBC driver and a connection string of simply DSN=SQLServerTest for the
migration.   Could you email me a script that creates an empty version of
your database in SQL Server ?  I can then create it here and see if I can
reproduce the error.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

When I used the SQL *native* driver then it started working, but eventually I received the error:

ElevateDB Error #100 There is an error in the metadata for the column Notes (The size is above the maximum of 512)

On another note, what is the data type you use to store strings in 2-8k range

Thanks

David

David,

<< When I used the SQL *native* driver then it started working, >>

What were you using prior ?

<< ElevateDB Error #100 There is an error in the metadata for the column
Notes (The size is above the maximum of 512) >>

Yes, you'll have to make sure that any CHAR or VARCHAR columns adhere to the
limitations for EDB.

<< On another note, what is the data type you use to store strings in 2-8k
range >>

CLOB

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim,

I was using the other SQL driver, not the native one, with regard to making my CHAR and VARCHAR columns compatible, should I just chnage any varchar columns over 512 to ntext, will your converter
know to turn them into CLOB.

Im think of putting the test on hold till the ADO dirver is available, we have a routine which will build the database using sql commands. So perhaps its best to wait and see, if its this weekend that the
ADO comes out then its best we wait.

Reagrds,

David

David,

<< I was using the other SQL driver, not the native one, with regard to
making my CHAR and VARCHAR columns compatible, should I just chnage any
varchar columns over 512 to ntext, will your converter know to turn them
into CLOB. >>

That's a good point.  I think I'll just modify the migration code to
automatically do that for you.  However, it could still cause problems if
you have any indexes defined for those columns.

<< Im think of putting the test on hold till the ADO dirver is available, we
have a routine which will build the database using sql commands. So perhaps
its best to wait and see, if its this weekend that the ADO comes out then
its best we wait. >>

The .NET data provider will work exactly like what you're already working
with in terms of the migration, etc.  In fact, there won't be any native
migration for .NET initially due to the differences required for the managed
space in terms of external assemblies, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com