Look in the File Layouts for decimal precision of fields.

The CI options are just what Sage allows (using the program), but the table structure is not based on that.

It's also possible the table has bad data.  Providex is not as strict as SQL when it comes to enforcing data types.

I would try creating a SQL Specific Pass Through Query and then creating a make table query based on that query.  A pass through query pulls data faster and with less errors as it gives the call directly to the server.  

I would think the ODBC would match the layouts given the way you define the object file in Nomads, I was thinking it could be bad data as well. Thanks!

I'm sure many of you know this, but just in case.

I use access to get Sage 100 table structures by linking a Sage table in Access.

Then I can copy the table link, and paste it as a new table. Access asks what you want in the new table..the table and it's data, or just the table structure.

Then I have an empty access table I can use as a reference..which I usually populate with custom sage queries.

cheers

Interesting idea, but what use do you have for a read-write Sage 100 table in MS Access?

The Access table link is "read only".

Here are a couple reasons I link tables:

1. I like the Access report tools.

2. Great way to browse system tables, mostly to locate corrupted records, that I would otherwise need to use the Data File Display and Maint tool.

3. Get table structure info which I then generally duplicate in POSTGRES, and transfer data using scheduled VISUAL Integrator jobs.

I find it much quicker to generate reports out of POSTGRES. Plus complicated reports can be a killer on the day to day

Sage performance. Not uncommon for me to get calls about Sage being slow, only to find some financial reports are being run.

My Sage users are spoiled!!