We have developed a framework around the cursoradapter that has produced an inconsistancy when run against FoxPro tables versus SQL Server tables. The following is a brief description of the NTier environment:

1. When our system starts up, a free table determines whether you want to go against FoxPro tables or SQL Server tables.
2. All of the datasources for both Fox and SQL tables are contained in a 'DataSources' free table, and read into properties on the startup object.
3. Depending on the modules the customer is using, the Business and Data tier objects are created from the list of modules.
4. The Logon form then is displayed. Once the user logs on with a valid password, the initial desktop form will be displayed.

Up to this point everything works great with either Fox or SQL as the data source.

5. Next all menu records are read from each applications menu table. These tables are used to create a cursor that will fill in a desktop tree control with user menu choices.

It's at this point where 2 of the 10 valid modules do not open up the table in SQL Server, but do open up in Foxpro.

The menu tables are identical in structure for all modules, the number and type of fields and indexes, yet only two fail to open up.

The data tier cursoradapter is identical between all modules except for the name of the table i.e. ar_mnu (which does not open) vs. ap_mnu which does open.

If I take the cursoradapter program logic out of the data tier and hard code it in the desktop presentation form, the ar_mnu table opens correctly. If I change the startup to use FoxPro tables as the cursor adapter source, it opens up correctly as an NTier system.

I have tried upsizing the data again to SQL Server, compared the fields, indexes and other table chacateristics to tables that do open and everything is identical.

Any ideas on what could be causing this behavior would be appreciated.