This project is read-only.

Unknown SQL datatype during Import

Jan 20, 2010 at 12:20 AM


I'm trying to import a database but getting errors. During the import with the new wsgen file wizard, I get an Connection String error dialogue, but can continue. Within the designer I can see the Tables and some Views.

I save the wsgen file, and change the SQL Server type to 2008, and try the Import from the Tools menu.

This time the Import progress dialogue steps through and after a delay an error dialogue opens with a trackback showing, "Unknown SQL datatype !"

It certainly does not look obvious that there is an unknown type, and it could be an erroneous error message. 

Verify shows errors on some Views. If I delete the views, then on save of the wsgen file, I get an Object not set error.


I'm hoping you'll be willing to fix the errors. You can reproduce easily if you create the database using
C:\Windows\Microsoft.NET\Framework\v2.0.50727>aspnet_regsql.exe, and then try to import.

I'm sure you'll get the same errors and I am not doing anything wrong.

It would be good to have an Import log file produced, to aid finding issues like this.

Many thanks for a very interesting product.







Jan 20, 2010 at 3:06 AM

You are right. There is an issue with the datatypes in SQL Server. The types nvarchar and sysnames have the same ID in the system tables. I do not know why. This was causing unpredictable results in the import process for views and stored procedures. This has been corrected and you can import this database after downloading the newest version.

Jan 20, 2010 at 12:37 PM

Many thanks for the speed of the fix. It is working now for Tables and Views, but I still have problems with Stored Procedures.
Seems more appropriate to log bugs within the Bug Tracker section, which is what I will do now. However, say if you want me to continue here.



Jan 20, 2010 at 2:27 PM

I have added a comment to the opened ticket. This is working as designed. Stored Procedures are not imported with columns. You need to add them manually. Stored Procedures have no defined return type. In your situation they probably do; however in general, a single Stored Procedure can return many different types or even multiple sets of data. As such, you will need to define what you expect back from the Stored Procedure.

Also keep in mind that when you import from an existing database your installation project will break too. This is because nHydrate is a platform for managing your entire database. It controls the names of defaults, indexes, relationships, primary keys, etc. Since you have an existing database, all of these names will be different from what nHydrate generates. You need to either remove all defaults, indexes, relationships, and keys then let nHydrate recreate them (it will do this when you run the installer) or come up with some other arrangement.

We may come up with a solution to import the exactly named objects and keep track of them for existing databases but this not currently in place.