2) As you know, the default behavior of an APPX application using a RDBMS is to use a commit mode of "Compatible". The intent of this mode is to allow an application that was designed to use APPXIO to be run with a database without requiring any changes to the application. Basically, if your application writes, rewrites, or deletes a record, APPX will immediately issue a commit to the database unless there is another record in another file that has also been read with hold but that has not yet been updated. If another record is held, APPX will wait until that record is updated before issuing a commit to the database. APPX must wait because a commit after updating the first record would cause the lock on the second record to be lost. As you know, updates to a database are not "permanent" until the commit occurs. The default behavior of SQLServer is to block any attempt to read a record that has been updated but not yet committed. This behavior increases the likelyhood that users will be blocked when they try to read a record (even if they are reading without a hold) that has been updated but not yet committed. In other words, users running an APPX application that uses SQLServer are more likely to see the dreaded "Waiting for locked record" message. It is hard to predict the impact of this issue. It really depends on the design of the application and the number of users who are running the system. But, I would assume that it will be more of an issue than it is with APPXIO. APPX processes that encounter/cause this issue can be re-engineered to avoid this problem. However, you probably won't be able to identify them all in advance.

It is possible to change the default behavior of SQLServer to allow "changed but uncommited records" to be read. This may be the best solution. But, if an APPX session crashes with uncommitted changes, then the uncommitted changes will be rolled back. This is OK but there is slight risk that uncommitted data might be read by another APPX session and then get rolled back if the session that updated the data crashes without ever executing a commit.

3) There is the potential for date mapping issues. SQL Server supports two date types: CC-th and CC-mm (that's CC-minutes). The smalldatetime type can only handle dates between 1900 and 2079.

4) VARCHAR (and CHAR) fields have a maximum length of 8000 characters, TEXT fields are essentially BLOB's (and are not indexable).

5) The maximum index size is 900 bytes. This should not be a problem since the maximum length of an APPX index is 256.

6) The maximum row size is 8060 bytes. This might be a problem since APPX allows a maximum record size of 32K.

7) Maximum column count (per-table) is 1024. This might be a problem if you have more than 1024 fields in an APPX file. Remember that each occurrance of an APPX field counts as a column in a table. So, if you have an APPX field with 30 occurrances, that will result in 30 columns in the database table.

8) Here's the important limitations:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_ts_8dbn.asp