Interfacing 3.7 SQL with .NET and odbc

MMorgan

I saw a reference in these forums that Navision should not be modified via ODBC, just C/ODBC, or database corruption may occur.

I'm in design phase of an application that handles return authorizations, and product tracking for repairable items to ensure timely returns to the customer. I've been basing my plans on ODBC, and ASP.NET.
After having read the post regarding data corruption, can someone clarify under what circumstances corruption can occcur?
It will be much easier to change design at this phase...

DenSter

All I can say is: Do NOT directly try to mimic Navision behaviour through an ASP application that writes directly to your SQL database. Be warned that this is tricky at best.

Navision uses SQL Server as the data back-end, and as such uses it in very specific ways (which is not documented in any SDK or anything). For instance Navision creates multiple copies of the same table for each company in the Navision database, following specific naming conventions. Furthermore, there are some indexing issues that replicate Navision native SIFT technology. If any of the tables that you want to write to have sumindex fields, or flowfields, then I would advise you to not even touch the table directly, unless you know how they implemented this technology, which I don't think you do.

MMorgan

I believe the sift triggers are implemented in the C/OBBC driver, and in the application itself. I doubt I'd be able to access them via ODBC.
I had not planned on modifying base table data, partially due to this.
I am, however, planning on modifying data in user tables that do not have flowfields, or SIFT indexes enabled.
I do hope to read the contents of the SIFT table in future projects..
Should I be safe in this, or should I consider a NAS for this project..