Tæller MS SQL forkert når den tæller rækker ?

Tja, har du checket om der er nogen af dine inserts der fejler?

Der kommer ikke nogen fejlmeddelelser i query-analyzer

hvis jeg kun indsætter 100 rækker tæller den forkert
også hvis det er rækkerne fra 100 til 200.

make a select count(*) to check who is right or wrong!

Hvis der ikke opstår nogle fejl, vil jeg næsten antage at det er et commit "problem". Hvis du indsætter fx 100 rækker med query-analyzer og derefter lukker dit qa-vindue, så burde din tabel også være opdateret herefter, fordi MS default kører med auto-commit.
Dvs. det er et spørgsmål om timing. Hvis der ingen fejl er, så bliver din tabel også opdateret korrekt.

En select Count(*) fra qa-vinduet efter indsættelsen vil også give dig det forventede antal rækker.

select count(*) from side
umiddelbart efter mine 200 inserts give 200
men når jeg dobbeltklikker på tabellen side viser den stadig "Rows: 199" også selvom jeg først lukker query analyzer.
Og jeg kan manuelt tælle at der er indsat 200 rækker.

Det jeg gerne vil være helt sikker på er bare om mine 200 rækker nu også er korrekt indsat (dvs MS-SQL har en tælle-fejl) eller der er en eller anden form for fejl i nogle af mine 200 insert-sætninger som på mystisk vis får MS-SQL til at tælle galt...

Ups mit 12:38:05 manglede et IKKE
hvis jeg kun indsætter 100 rækker tæller den IKKE forkert
også hvis det er rækkerne fra 100 til 200.

dobbeltklikker,what program are you using!

har du i QA omkranset dine inserts af "BEGIN TRANS" og "COMMIT TRANS" ?

terry>
jeg bruger enterprise manager. Når man til højre har alle tabellerne og dobbeltklikker på en tabel kan man se tabeldefinitionerne for tabellen og antallet af rækker i tabellen

larildsen>
Nej jeg har ikke "begin trans" og "commit trans" omkring, men jeg kan ikke forstå at det skulle kunne have nogen betydning ?

Det giver nok ikke det hele at køre det i en transaction, men bare lige for at vide det.
Jeg har på andre DB platforme (f. eks. Oracle) set problemer med array fetch, der via ODBC har returneret prefetch count - 1 række, osv.
Jeg skal ikke gøre mig klog på dette, men det lugter af et ODBC problem.
Hvilken MDAC kører du, og hvilken driver version anvender du.
Anvender du ODBC eller OleDB eller ?

larildsen>
Alt jeg ved er at jeg bruger en DSN som jeg går ud fra betyder at det er en ODBC.

Men jeg kan ikke se hvad betydning det skulle have. Så vidt jeg kan se bliver alle mine inserts jo udført, men enterprise manager påstår at der er færre rækker i min tabel end jeg rent faktisk kan se.

Prøv med en "update" af tabellerne før du forespørger efter din opdatering.

Det hjælper ikke med en update.
hvis jeg rydder databasen, laver mine 200 insert i QA, lukker QA, lukker enterprise mangager, åbner enterprise manager og klikker på tabellen står der Rows: 199. Går jeg ind i tabellen og kigger på indholdet kan jeg tælle 200 rækker og hvis jeg laver en count(*) i QA siger den 200.

Jeg skal så lige sige at det ikke kun er insertsætninger idet jeg først laver en create af tabellen.

Jeg må også sige at jeg ikke har kunnet få "BEGIN TRANS" og "COMMIT TRANS" til at virke -- det er vist ikke den rigtige syntaks.

Jeg tror på en eller anden måde at der er fejl i MS_SQL.
Jeg har før fundet en fejl i QA hvor den ikke vil udføre en drop table lige før en create table hvis der er underscore i navnet (så vidt jeg lige husker) -- det jeg mener er bare at det vel ikke er helt usandsynligt at der kan være fejl i MS-SQL ?

Jeg tror umiddelbart at det nærmere er en fejl i enterprise manager der er skyld i problemet. I et recordset med 200 rækker hedder 1. record jo 0 og sidste 199 - kan det være forklaringen?

Det forklarer selvfølgelige ikke at forskellen bliver større og større ;)

Hm måske er jeg kommet nærmere en forklaring.

Min tabel har et identity-felt så jeg bruger
SET IDENTITY_INSERT [side] ON før insertsætningerne og
SET IDENTITY_INSERT [side] OFF efter insertsætningerne

Da jeg prøvede med 200 inserts havde jeg en
SET IDENTITY_INSERT [side] OFF;
SET IDENTITY_INSERT [side] ON;
imellem den 100 første og de 100 sidste insertsætninger.

Men det kan nu ikke være hele forklaringen for med kun få inserts og mange off on´s kan jeg ikke få den til at tælle forkert

Jeg fandt dette på dbforums:

The GUI EM uses the rowcount data held in the column rows in the table sysindexes in your database, which is updated as a secondary task to the main database, and sometimes takes a little longer. This is one of the reasons that the EM GUI has a REFRESH button everywhere.

I'd not personally classify it as a bug, rather a feature that is attendant with most GUI's. How do you force updates to the GUI out of the lower level data in realtime, and is it necessary in most circumstances? The refresh option is the strategic plan at this stage whenever using the EM GUI otherwise feel confident in the use of the TSQL.

If you schedule the same experiment after hours you will find that by that time all is in synch, whereas during peak load the updating lag can be noticeable.

Farmer Brown Falls Creek, Australia

Interessant.

Tror du det måske betyder at hvis jeg venter et par timer efter mine inserts er udført med at kigge igen så tæller den pludselig rigtig ?

Ja, måske. Det er ikke så smart (for at sige det mildt), men du kan da altid stole på at en "select count(*)" giver det øjeblikkelige antal rækker.
Gad vide om man kan gennemtvinge en opdating af sysindexes? Prøv med:

UPDATE STATISTICS side

i query analyzer.

Det har ikke hjulpet at vente en dag -- den viser stadig forkert.
UPDATE STATISTICS gør ingen forskel.

Hvis jeg omdøber min tabel tæller den stadig forkert
Hvis jeg indsætter een ekstra række tæller den en op (men stadig det forkerte antal) -- Men count(*) viser altid det rigtige, så jeg jeg regner med (indtil det modsatte er bevist) at der er tale om en fejl i MS SQL som jeg må leve med.

Takke mange gang for interessen