Worrying SQL Server and Access table displays
Hi
I have a table (originally in an Access DB) now since a while in SQL Sever (2005). This table has a split primary (unique) key composed of 4 fields, one fixed-length string and 3 number (integer and byte) fields. Since ever, it displays in Access (2007 and 2013) always nicely in PK sequence, never had any problems with it. However, when I migrated the contents of the table from Access to SQL Server, I was always puzzled by the fact that SQL Server did not display the data in PK sequence. But I had seen that in SQL Server in other tables in other projects and instances, so I did not worry, because in Access, which is used as front-end, it always displayed as expected, in PK sequence. Until this morning, that is !
Yesterday, I added an index on one field of this table in SQL Server. I certainly did not think that that would create the complete chaos that ensued.
This morning, some of my users reported a strange thing happening in a report based on that table. When I looked over Access at the table, I nearly had a heart attack. Lots of rows seemed to be missing. Looking more at the table, I discovered that all rows were actually there, but they were NOT displayed in PK sequence anymore !!!
I refreshed the link. No change. I de-linked and relinked the table. No change, still a completely jumbled display ! So I decided to delete the newly created index in SQL Server, as this was the only change done to the DB. And, presto, after refreshing the table link, it displayed again in PK sequence !
I have NEVER seen such a thing before. What can drive Access to show a table NOT in PK sequence, when it shows in design mode that it has a unique (albeit multi-part) key ?
Even weirder was the fact that it looked like that some queries and reports would obviously find the underlying table in PK sequence, and others not.
Have you ever experienced something like that ?
Thanks for your opinions and hints.
Bernard
I have a table (originally in an Access DB) now since a while in SQL Sever (2005). This table has a split primary (unique) key composed of 4 fields, one fixed-length string and 3 number (integer and byte) fields. Since ever, it displays in Access (2007 and 2013) always nicely in PK sequence, never had any problems with it. However, when I migrated the contents of the table from Access to SQL Server, I was always puzzled by the fact that SQL Server did not display the data in PK sequence. But I had seen that in SQL Server in other tables in other projects and instances, so I did not worry, because in Access, which is used as front-end, it always displayed as expected, in PK sequence. Until this morning, that is !
Yesterday, I added an index on one field of this table in SQL Server. I certainly did not think that that would create the complete chaos that ensued.
This morning, some of my users reported a strange thing happening in a report based on that table. When I looked over Access at the table, I nearly had a heart attack. Lots of rows seemed to be missing. Looking more at the table, I discovered that all rows were actually there, but they were NOT displayed in PK sequence anymore !!!
I refreshed the link. No change. I de-linked and relinked the table. No change, still a completely jumbled display ! So I decided to delete the newly created index in SQL Server, as this was the only change done to the DB. And, presto, after refreshing the table link, it displayed again in PK sequence !
I have NEVER seen such a thing before. What can drive Access to show a table NOT in PK sequence, when it shows in design mode that it has a unique (albeit multi-part) key ?
Even weirder was the fact that it looked like that some queries and reports would obviously find the underlying table in PK sequence, and others not.
Have you ever experienced something like that ?
Thanks for your opinions and hints.
Bernard
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@Victor
I just looked. The PK is clustered. AND SQL Server shows me now for the first time the rows in PK sequence, which id did NOT do this morning ! So deleting an index forced it to re-arrange the data ?
@Jim
I've NEVER ever seen a single table in Access not showing in PK sequence. And that even in Access DBs which not compacted/repaired for more than a year. But then my volumes have always been pretty small, that's maybe the reason ?
I just looked. The PK is clustered. AND SQL Server shows me now for the first time the rows in PK sequence, which id did NOT do this morning ! So deleting an index forced it to re-arrange the data ?
@Jim
I've NEVER ever seen a single table in Access not showing in PK sequence. And that even in Access DBs which not compacted/repaired for more than a year. But then my volumes have always been pretty small, that's maybe the reason ?
<<I've NEVER ever seen a single table in Access not showing in PK sequence. And that even in Access DBs which not compacted/repaired for more than a year. But then my volumes have always been pretty small, that's maybe the reason ? >>
Yes. If Jet can populate a recordset in the first go around, the set will be ordered. If it needs to go back, they will be unordered.
When you open a table or query, Jet tries to balance fetching the records vs giving you a response. If it decides there is too much data to get it done quickly, it will return control to Access while it continues to populate the record set in the background.
You can see this when opening a table or query and the number of records doesn't populate right away. Unless you click a move to last, you may not have everything.
You also see this when opening a record set in code, the record count at first may not be accurate. All you can be sure of is if you have records or not. You have to issue an explicit MoveLast to force Jet to fully populate the set before returning control.
Jim.
Yes. If Jet can populate a recordset in the first go around, the set will be ordered. If it needs to go back, they will be unordered.
When you open a table or query, Jet tries to balance fetching the records vs giving you a response. If it decides there is too much data to get it done quickly, it will return control to Access while it continues to populate the record set in the background.
You can see this when opening a table or query and the number of records doesn't populate right away. Unless you click a move to last, you may not have everything.
You also see this when opening a record set in code, the record count at first may not be accurate. All you can be sure of is if you have records or not. You have to issue an explicit MoveLast to force Jet to fully populate the set before returning control.
Jim.
I've NEVER ever seen a single table in Access not showing in PK sequence.I saw one just yesterday at a client's site. Compact and Repair fixed it, but before it was showing as jumbled. This was Access-based data. I can't say I've seen it with SQL Server data, but then anytime I view data in a project I create, I include an Order By clause.
Recreating indexes can certainly force records to be displayed in a particular order, according to whatever the database engine wants. But assuming that records will always be in PK order will ultimately lead you to where you're at.
Bottom line: If you want to see records in a specific order, then use an ORDER BY clause.
@Victor
I just looked. The PK is clustered. AND SQL Server shows me now for the first time the rows in PK sequence, which id did NOT do this morning ! So deleting an index forced it to re-arrange the data ?
No, deleting an index doesn't force a data rearrange unless you are deleting a clustered index.
What could happened here is that occurred a reindex. You can check in SQL Server agent for reindex job just to confirm it.
You'll generally get records returned in PK sequence up to a point and then things will become un-ordered.
And that's by design. Tables are considered in relational designs as an un-ordered set of records. That's the basic definition of a table (relation)
Jim.