Einzelnen Beitrag anzeigen

noisy_master

Registriert seit: 17. Jun 2009
Ort: Wolfenbüttel/Baddeckenstedt
257 Beiträge
 
Delphi XE5 Professional
 
#37

AW: DBGrid und Touchscreen

  Alt 14. Okt 2010, 08:26
Ich will mal die Fragezeichen noch aufklären

Du hast nicht erklärt,
- um wie viele Datensätze es sich handelt
- wie oft die Query aktualisiert wird
- wie komplex die Joins sind
- wieviel Daten geändert werden können
- was Du als zeitkritisch beim Scrollen betrachtest
- ob es pro Datensatz eine eindeutige und aufsteigende ID gibt
- (ob es Alternativen zur BDE gibt)

Daher muss ich bzw. müssen wir etwas orakaln...
Als Ansätze würde ich grundsätzlich folgendes sehen:

1) Daten in Objekten verwalten und zurückschreiben (wie der Sir meinte)

2) temporäre Tabelle erstellen (und TTable benutzen) und nach den Änderungen wieder in die originalen Tabellen zurüchschreiben

3) DBGrid.DrawDataCell
Sofern Du ein eindeutiges Indexfeld in der Ergebnismenge hast, kannst Du diesen Wert wärend des Zeichnens der Zellen ermittel. Das wird z.B. genutzt, um DBGrid-Zeilen, bei Negativwerten rot zu färben.
Du könntest das verwenden, um die Button zu (de-)aktivieren. Dazu müsstest Du den niedrigsten und höchsten Wert kennen und darauf abgleichen. Das ist nicht simpel, aber durchaus möglich.
Es wäre auch möglich, nach dem Abrufen einer Query alle "Indizes" in eine Stringlist zu kopieren und beim scrollen die Postion aus der Stringlist zu ermitteln.
MyCursor := StringList.IndexOf(MyField.AsString) + 1; Das ist alles nicht optimal, aber was für Dich das sinnvollste ist, musst Du letztlich selbst entscheiden (je nachdem was genau für Daten vorliegen und was Du mirt dem Projekt weiter vor hast).
Nachdem du denn nun schon soviel geschriebe hast will ich deine Fragen mal nicht unbeantwortet lassen:

Alternative zur BDE: im Moment nicht!
Aufsteigende eindeutige ID: ja gibt es, aber leider keine kontinuierliche
Was ich als Zeitkritisch betrachte: Wenn ich mi anschaue, in welcher Geschwindigkeit die Jungs im
Restaurant auf den Screen einhämmern möchte ich jede (unnötige/umgehbare) Geschwindigkeitseinbuße vermeiden.
Wieviele Daten können geändert werden: nicht allzuviele( Bestellung kommt hinzu, Artikel kommen hinzu, es wird gedruckt... also immer nur einzelne Felder/einzelne Datensätze)
Wie komplex sind die Joins: nicht allzusehr, jeweils einzelne Verweise auf Kellnernummern bzw Artikelnummern oder Rechnungsnummern
Wann wird das Query aktualisiert: immer dann, wenn sich an den Datensätzen was ändert.
Wieviele Datensätze: Ein klares kommt drauf an : Wenn viel los ist sind es mehr... Nun nochmal ohne Scherz: Nimm die eine durchschnittliche Pizzeria mit meinetwegen 30 Tischen und 2 Bedienungen-> Anzahl offenen Bons ~max 15 und Artikel/Bestellung je nach Hunger der Kunden also ~20 Artikel pro Bestellung

Hält sich in Summe in Grenzen, aber wenn sich an irgendwelchen Stellen durch geschicktes programmieren Performance gewinnen lässt ist das immer gut.

Deinen Aussagen zu den bisherigen Vorschlägen stimme ich zu.
Dirk
  Mit Zitat antworten Zitat