SQL Server Compact Edition - Index Problem

Hallo,

ich habe folgende Tabelle:

create table objaus(objnr int, anr int, ajahr int, barcode nvarchar(20), evt DateTime, remidatum datetime, endtermin datetime, vdznr int, vkpreis real, ehpreis1 real, mwst real)

Folgender Index noch dazu:

create index idx_objaus on objaus (objnr, anr, ajahr)

Die Abfrage:

select a.objnr, a.anr, a.ajahr, b.titel, evt, remidatum, endtermin, vkpreis, ehpreis1, mwst from objaus a, objekte b where a.objnr = b.objnr and barcode like '{0}%' order by b.titel, ajahr desc, anr desc

funktioniert dann mit folgenden Code:

[...]
SqlCeDataAdapter oDA = new SqlCeDataAdapter(string.Format(sqlLoadObjBarcode, barcodeString), objCon);
                    try
                    {
                        DataSet oDS = new DataSet("objekte");
                        oDA.Fill(oDS);
                        if (oDS.Tables[0].Rows.Count > 0)
[...]

problemlos und "if (oDS.Tables[0].Rows.Count > 0)" ergibt true. Neuer Versuch mit dem gleichen Barcode, aber anderen Index:

create index idx_objaus on objaus (barcode, objnr, anr, ajahr)

liefert bei "if (oDS.Tables[0].Rows.Count > 0)" false zurück, obwohl genau die gleichen Daten verwendet werden. Sobald ich wieder den alten Index verwende (drop index und danach wieder neuanlegen) funktioniert es wieder.

Wieso beeinflusst der Index das Abfrageverhalten und wie kann ich einen Index auf Barcode haben, so dass auch die Abfrage noch funktioniert?

Viele Grüße
Thomas

Groß- / Kleinschreibung ? Sonderzeichen ?

Das SQL ist haargenau das gleiche, nur gibt es einmal einen Index auf Barcode und einmal nicht. Ohne Index funktioniert es und mit einem Index auf Barcode nicht. Also sollte der Inhalt der Barcodespalte irrelevant sein, oder? Sind eh nur Zahlen drin .... jetzt wo ich das schreibe, werde ich doch glatt mal den Datentyp ändern. Vielleicht bringt das was.

Nicht das das ein ähnlicher Bug wie hier ganz unten beschrieben ist: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1193249&SiteID=1

So Datenformat von der Spalte Barcode in "bigint" umgewandelt, aber leider besteht das Problem immer noch.

Hab mal testweise ein einfacheres SQL implementiert.
Mit Index auf die Spalte Barcode liefert die folgende SQL Anweisung kein Ergebnis zurück:

select objnr from objaus where barcode like '41904432100081'

Ohne Index auf die Spalte Barcode bei den gleichen Daten und oben genannten SQL wird das richtige Ergebnis 1938 für das dem Barcode entsprechende Objekt zurückgeliefert.

[EDIT]Mit dem SQL:

select objnr from objaus where barcode = '41904432100081'

funktioniert es mit und ohne Index. Ich brauche aber in dem Fall die Variante mit "like", da es vorkommen kann, dass der Barcode nicht komplett gelesen wurde und somit nur ein Teil mit dem in der datenbank hinterlegten Barcode übereinstimmt. Für den Fall soll der Benutzer alle möglichen Objekte aufgelistet bekommen und das geht dann nur mit barcode like "xy"

[EDIT 2]Wenn ich beim Erstellen der Tabelle gleichen einen primären Key auf die Spalte Barcode lege, dann funktioniert es !? Komisch ...

create table objaus(objnr int, anr int, ajahr int, barcode bigint primary key, evt DateTime, remidatum datetime, endtermin datetime, vdznr int, vkpreis real, ehpreis1 real, mwst real)

Hallo Hitzi,

ich benutze die Suche mit "like" oft und habe mal alle Kombinationen mit dem SQL Server Compact ausprobiert. Ich konnte keine Fehler feststellen.

Grüße Bernd

ich wußte noch garnicht das like auch auf spalten die vom typ her keine zeichenketten sind funktionieren o.O

Ich habe auch unter anderen noch eine andere Tabelle in der Datenbank:

create table objekte(objnr int primary key, titel nvarchar(50))

mit zusätzlichen Index auf Titel:

create index idx_objekte on objekte (titel)

und ein Select auf die Objektnummer:

select objnr from objekte where name like "%mo%"

und das funktioniert ohne Probleme. Genauso gibt es noch einen Kundentabelle wo ein zusätzlicher Index auf dem Namen liegt und auch da funktioniert alles mit like wie es soll. Nur bei dem Barcodebeispiel zickt er rum.

Aber jetzt mit dem primary Index auf Barcode ist die Abfrage auch nicht wirklich schneller geworden. Kann ich mir also sparen.

wie ich schon schrieb, mir war bisher nur bekannt das like bei zeichenketten funktioniert, nicht aber bei int und so... war ic hda bisher einem irrtum verfallen oder liegt hierin das problem das du nichts zurück bekommst?

Der Irrtum liegt auf deiner Seite 😉

Primary Key auf Barcode (Typ bigint) gleich beim Erstellen der Tabelle und eine Abfrage wie folgt:

select objnr from objaus where barcode like '41904432100081'

funktioniert! Bringt aber leider keinen Geschwindigkeitsunterschied zu der Variante ohne dem Index auf die Spalte Barcode.

geht auch sowas?

select objnr from objaus where barcode like '41%'

LIKE (SQL Server Everywhere)

Determines whether a given character string matches a specified pattern. A pattern can include regular characters and wildcard characters. During pattern matching, regular characters must match exactly the characters specified in the character string. Wildcard characters, however, can be matched with arbitrary fragments of the character string. Using wildcard characters makes the LIKE operator more flexible than using the = and != string comparison operators. If any of the arguments are not of a character string data type, Microsoft SQL Server 2005 Everywhere Edition (SQL Server Everywhere) converts them to a character string data type, if possible.

Syntax

match_expression [ NOT ] LIKE pattern [ ESCAPE escape_character ]

Arguments
match_expression
Any valid expression in SQL Server Everywhere of nchar, nvarchar, or ntext data type.

pattern
The pattern to search for in match_expression. It can include the following valid SQL Server Everywhere wildcard characters:

Wildcard character Description Example
%
Any string of zero or more characters.
WHERE title LIKE '%computer%' finds all book titles with the word 'computer' anywhere in the book title.

_ (underscore)
Any single character.
WHERE au_fname LIKE '_ean' finds all four-letter first names that end with ean, such as Dean or Sean.

escape_character
Any valid expression in SQL Server Everywhere of any of the data types of the character string data type category. The escape_character argument has no default and must consist of only one character.

Result Types
bit

Return Value
LIKE returns TRUE if the match_expression matches the specified pattern.

Yup, funktioniert. Auf der Basis baut ja meine Objektauswahl auf, falls der Barcode nicht vollständig erkannt wird (wenn zum Beispiel der AddOn fehlt).

Ich versteh das Ding (Compact SQL Server) nicht!
Gestern hatte ich mal einen extra Index (andere Indexname) nur für den Barcode erstellt und war beim folgenden Test erstaunt, dass die Barcodeerkennung nun um ein vielfaches schneller war.

Nach einer Datenaktuallisierung war dieser Geschwindigkeitsschub wieder weg, obwohl nichts am Code/Indexerstellung geändert wurde. Da hab ich dann die Datenbank nochmal komplett gelöscht und über das programm wieder neu erstellen lassen. Aber auch über diesen Weg gab es keine Möglichkeit, die Barcodeerkennung wieder zu beschleunigen. 🙁

Das Beste am Schluss ... bei meinen heutigen Tests hab ich spaßeshalber mal wieder den Barcodeindex so erstellen lassen, wie im ersten Beitrag hier genannt. Plötzlich liefert das SQL auch in dieser Konstellation Werte zurück, was gestern zur gleichen Zeit nicht funktionierte!

Ich glaub zwar kaum, dass jemand mir das erklären kann, aber wenn doch immer raus damit. Ich würde schon gern wissen, auf was ich achten muss, um so ein scheinbar zufälliges Verhalten nicht zu provozieren.

Gruss
Thomas