Post reply

2000 to 2005: "INITCOLVS is not a recognized built-in function name"

  • February 20, 2008 at 3:55 pm

    #183254

    Hello,

    One of our applications the FoxPro-based has a problem inserting data when tested with SQL Server 2005. The production version works with SQL Server 2000 without problems. The error message from ODBC SQL Server Driver is:

    "INITCOLVS is not a recognized built-in function name"

    This problem is the same as in one of the posts on another forum here:

    http://www.sqlservercentral.com/Forums/Topic268895-148-1.aspx#bm269880

    I did do a search, on the web it looks like related to the replication (?) but no solutions were provided. There are very few posts on the subject and BOL does not contain any reference on this function.

    The production database does participate in the merge replication, but the database in 2005 is not replicating, it is just an individual copy of the database moved to the test 2005 environment. Also, the insert problem happens only on one table. Other tables in 2005 do allow insert through the application.

    Please, let me know if anybody else has experience with this error message.

    Regards,Yelena Varsha

  • April 30, 2008 at 1:51 pm

    #809301

    Hi,

    I ran into this problem as well while using a backup/restore method to put a SQL 2000 DB into my development environment which used a SQL 2005 server.

    After some research followed by some testing, it appears this error is caused by some legacy triggers used for merge replication created by SQL 2000. In the simplest sense, you can delete the offending trigger off of the table you are attempting to insert into on your SQL 2005 db, but this is certainly not the best fix in my mind as every table that is replicated will have errors inserting new records due to this trigger (or it's table-specific variation).

    I have read some posts relating this issue to the level of compatibility of the database, and I have tried both 80 (sql2000) and 90 (sql2005) as well as running a Copy DB with the higher level of compatibility, but in both cases the triggers and inherent errors still exist.

    So for the time being I will remove this offending trigger (ins_******************) and drive on, but if anyone knows of a better or more complete solution, please let us know!

    Thanks,

    Erik Roll

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply