SQL Relation

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

SQL Relation

Beitrag von AUGE_OHR »

ich kann mehrere Email Attachmens haben

in xBase hätte ich mehrer Möglichkeiten einer Verknüpfung mit einer anderen DBF

Code: Alles auswählen

SELECT 1
USE Emails ALIAS EMAILS 
SET Index EM_ID
SELECT 2
USE Attachments ALIAS ATM 
SET Index AT_ID

Code: Alles auswählen

* --- Relation --- *
SELECT 1
SET RELATION TO EMAILS->ID INTO ATM
IF ATM->( Found() )

Code: Alles auswählen

* --- Scope --- *
ATM->( DBSEEK(EMAILS->ID) )
IF ATM->( Found() )
   ATM->( DbScope(EMAILS->ID) )

und wie mache ich das nun unter SQL :?:
alles in 1 Abfrage oder wie beim Scope 2 Schritte :?:
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: SQL Relation

Beitrag von georg »

Hallo, Jimmy -


SELECT feld1, feld2, feld3 ... FROM table1 LEFT JOIN table2 ON feld1 = feld7 WHERE feld2 = 'Garten' ORDER BY feld17

Es gibt verschiedene Formen des JOIN, allerdings keine, die 100 % dem entspricht, was set Clipper-Zeiten mit dem SET RELATION gemacht wird.

Den SCOPE regelst Du mit der WHERE-Bedingung.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von brandelh »

Viel habe ich ja nicht damit gemacht, aber so wie ich das verstanden habe ist ein JOIN wie ein Array das alle Datensätze enthält.
Also angenommen 5 Rechnungen in RechKopf und je 200 Positionen in RechPosition, würde ein 5 * 200 Datensätze liefern, wenn man die Daten alle in einer Liste braucht, z.B. um den Inhalt zu drucken etc. ist das gut.
Wenn ich aber z.B. sehr große Datenbestände habe, ziehe ich es vor zuerst den Kunden, dann die Liste der Rechnungen und nach Auswahl die Positionen einer Rechnung anzuzeigen, das mache ich dann in 3 Abfragen, minimale Daten.
PS: auf Xbase++ Relationen habe ich mich schon ewig nicht mehr verlassen, dort habe ich es entweder per Array wie bei Join oder auf die Zweite Möglichkeit gemacht, je nach Aufgabe.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

Danke für eure Antworten.

es geht mir weniger um die Syntax sondern mehr um ein Konzept.
wenn ich z.b. 3 Attachments habe wie stelle ich die in einer Liste dar ?

wenn ich mit 2 x DBF arbeite würde ich die auch in 2 x Browse darstellen wobei das 2nd Browse durch Relation oder Scope begrenzt wird.
wenn ich nun mit JOIN arbeite und im Result Set "alles" habe wie bekomme ich das wieder "auseinander" :?:

deshalb die Frage ob 1 Schritt oder 2 Schritte mit SQL.
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: SQL Relation

Beitrag von georg »

Hallo, Jimmy -


in dem von Dir beschriebenen Fall solltest Du mit zwei SELECT arbeiten. Der erste SELECT befüllt den ersten Browse. Ausgehend vom ausgewählten Datensatz im ersten Browse erzeugst Du einen zweiten SELECT, der durch die ausgewählte Zeile des ersten Browse eingeschränkt wird.

Unterstellen wir, dass der erste Browse die Felder EMAILID, SUBJECT und SENDER enthält, dann wäre das:

Code: Alles auswählen

SELECT emailid, subject, sender FROM emailinbox ORDER BY (nach Lust und Laune)
Wird jetzt der Satz mit der EMAILID 935 ausgewählt, wäre der SELECT für den zweiten Browse etwas so:

Code: Alles auswählen

SELECT <xxx> FROM emailattach WHERE emailid = 935
Hier wären prepared statements eine klasse Sache.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

moin,

ok also mit 2 x SELECT
die beiden SELECT sind soweit klar. aber wann/wie starte ich die 2nd Anfrage ...

bei SET RELATION wird die 2nd DBF automatisch (durch DBE ?) auf die Position gebracht.
bei einem SCOPE warte ich auf das o:Stabil bzw. führe den o:stableBlock Codeblock aus.

nun habe ich bei DBF ein ALIAS aber wenn ich ein neues SELECT ausführe hab ich ja nicht mehr das "alte" Result Set.
ohne Result Set könnte ich dann ja nicht mehr im 1st Browse navigieren (es sei denn ich hab vorher ein Array gemacht).

also das ganze dann mit einer neuen Connection im Thread :?:
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von brandelh »

das kommt drauf an mit was du arbeitest, wenn du ein Object des resultses von 1 bekommst ist das vom 2. unabhängig.
Ich persönlich neige dazu alles in Arrays einzulagern, da ich wenig Erfahrung habe und mich nicht mit den verschiedenen Resultsets Verhalten auseinandersetzen will.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von Jan »

Hubert,

mit einem SELCT kann man ja in Xbase++ die "gefilterten" Daten automatisch in ein Array (INTO aArray) oder DataObject (INTO OBJECTS aArray) schreiben. Das macht die ganze Sache dann wesentlich einfacher und übersichtlicher.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: SQL Relation

Beitrag von georg »

Hallo, Jimmy -


SQL ist nicht DBF.

dbSetRelation() hat eigentlich keine SQL-Entsprechung.

Unterstellen wir mal folgende Tabellen:

Tabelle A:

Code: Alles auswählen

+----------+------------+
! ID       ! Datum      !
!        1 ! 02.03.2018 !
!        2 ! 02.03.2018 !
+----------+------------+

Code: Alles auswählen

+----------+------------+
! ID       ! Anhang     !
!        1 ! ABCDEFGHIJ !
!        1 ! BCDEFGHIJK !
!        2 ! CDEFGHIJKL !
+----------+------------+
Ein dbSetRelation() liefert Dir eine Verbindung mit dem 1. gefundenen Satz in der Child-Tabelle:

Code: Alles auswählen

+----------+------------+------------+
! ID       ! Datum      ! Anhang     !
!        1 ! 02.03.2018 ! ABCDEFGHIJ !
!        2 ! 02.03.2018 ! CDEFGHIJKL !
+----------+------------+------------+
Dahingegen liefert ein SELECT * FROM tablea LEFT JOIN tableb ON tablea.id = tableb.id folgendes Ergebnis:

Code: Alles auswählen

+----------+------------+------------+
! ID       ! Datum      ! Anhang     !
!        1 ! 02.03.2018 ! ABCDEFGHIJ !
!        1 ! 02.03.2018 ! BCDEFGHIJK !
!        2 ! 02.03.2018 ! CDEFGHIJKL !
+----------+------------+------------+
DBF verhält sich "anders", da der Fokus auf der ersten Tabelle liegt, wird halt erst einmal der erste Treffer in der zweiten Tabelle gesucht and bereitgestellt, während SQL direkt ein komplettes Ergebnis (result set) liefert.

Da Du bei SQL aber den Satz mit der ID 1 aus tablea nur einmal im Browse sehen willst, musst Du also für beide Browses ein eigenes result set verwenden, wobei das zweite immer dann aktualisiert werden muss, wenn die Bewegung im ersten Browse auf einem Datensatz zur Ruhe gekommen ist.

Da ich ein solches Konstrukt noch nicht eingesetzt habe, kann ich Deine Frage
die beiden SELECT sind soweit klar. aber wann/wie starte ich die 2nd Anfrage ...
leider nicht beantworten.

Die Frage
also das ganze dann mit einer neuen Connection im Thread
verstehe ich nicht ganz. Von daher kann meine Antwort auch falsch sein. Die Connection ist die Verbindung vom Programm zum SQL-Server. Auf dieser Connection kannst Du beliebig viele SQL Queries laufen lassen. Du brauchst also für das zweite result set keine neue Connection. Du solltest jedoch daran denken, nicht mehr benötigte result sets zu schliessen. Bei Hector's Klasse wäre das dann ein :close() bei Verwendung der MyResult()-Klasse.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: SQL Relation

Beitrag von Werner_Bayern »

AUGE_OHR hat geschrieben: Mi, 20. Jun 2018 8:31 ok also mit 2 x SELECT
die beiden SELECT sind soweit klar. aber wann/wie starte ich die 2nd Anfrage ...
Wie bisher auch:

Code: Alles auswählen

oBrowse:itemMarked
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

Werner_Bayern hat geschrieben: Mi, 20. Jun 2018 12:02
Wie bisher auch:

Code: Alles auswählen

oBrowse:itemMarked
[/quote]das o:itemMarked feuert IMHO sobald ich auf einem Datensatz stehe aber dann ist das Browse evtl. noch nicht "Stable"

angenommen ich habe 10 Sätze und stehe auf dem 5th und betätige PgDn.
der DbSkipper baut also 11-15 auf und "merkt" das ich auf der Row 15 stehe -> o:itemMarked

wenn das nun auf ein anderes ALIAS geht werden 16-20 im 1st Browse nicht mehr sauber aufgebaut.
erst wenn alle 10 Zeilen vorhanden sind ("Stable") darf deshalb dann erst die Aktion durchgeführt werden
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

georg hat geschrieben: Mi, 20. Jun 2018 8:54 Dahingegen liefert ein SELECT * FROM tablea LEFT JOIN tableb ON tablea.id = tableb.id folgendes Ergebnis:

Code: Alles auswählen

+----------+------------+------------+
! ID       ! Datum      ! Anhang     !
!        1 ! 02.03.2018 ! ABCDEFGHIJ !
!        1 ! 02.03.2018 ! BCDEFGHIJK !
!        2 ! 02.03.2018 ! CDEFGHIJKL !
+----------+------------+------------+
DBF verhält sich "anders", da der Fokus auf der ersten Tabelle liegt, wird halt erst einmal der erste Treffer in der zweiten Tabelle gesucht and bereitgestellt, während SQL direkt ein komplettes Ergebnis (result set) liefert.
JA, das ist was ich mit "alles drin" meine was man dann wieder "zerlegen" müsste.

im Grund hätte ich wohl gerne ein mehrzeiliges Browse ... oder was zum "aufklappen" ...
oder ich zeige nur die Anzahl der Attachments und man muss einen Button drücken um an die ran zu kommen.
oder ein ganz neues Control mit Listview zum "aufklappen" ... mal sehen was am besten geht.
---
Die Connection ist die Verbindung vom Programm zum SQL-Server. Auf dieser Connection kannst Du beliebig viele SQL Queries laufen lassen. Du brauchst also für das zweite Result Set keine neue Connection.
JA ... da habe ich mich schlecht ausgedrückt.

Thread deshalb weil ich da ja unabhängig je eine Query laufen lassen kann d.h. ich "verliere" das Result Set nicht wenn ich in einem anderen Thread eine neue Query mache.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von brandelh »

dazu musst du erstmal schreiben, mit was du auf SQL Dateien zugreifen willst !

Ich vermute NICHT mit der PqDBE der Version 2.0 ;-)

Wenn ein Resultset in einer Objekt Variablen gekapselt ist, dann sollten mehrere gleichzeitige Abfragen und Resultsets kein Problem darstellen.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von brandelh »

Jan hat geschrieben: Mi, 20. Jun 2018 8:50 Hubert,
mit einem SELCT kann man ja in Xbase++ die "gefilterten" Daten automatisch in ein Array (INTO aArray) oder DataObject (INTO OBJECTS aArray) schreiben. Das macht die ganze Sache dann wesentlich einfacher und übersichtlicher.
Jan
wenn man die PgDBE nutzt ;-)

Mit SQLexpress() war es schon immer so, dass man eine Variable für die Verbindung, für jedes Statement bzw. einen Cursor anlegt und diesen dann nutzt:

Code: Alles auswählen

oCursor := oConn:Cursor("SELECT count(*) FROM UVCD") // Anzahl Datensätze abfragen, hier Abfrage aufbauen
oCursor:Execute()  // und ausführen
oCursor:RecCount() // wie viele Zeilen sind im Cursor vorhanden
oCursor:FieldGet(1) // Bei dieser Abfrage gibt es nur eine Zeile und im ersten Feld steht die Anzahl
Ich habe nicht viel damit gemacht, aber wie andere schon geschrieben haben, soll es sogar direkte Unterstützung für das Browsen geben.
Wenn man die direkten Mapper von MySQL oder PostGreSQL nutzt sieht die Syntax natürlich etwas anders aus, aber eigentlich darf es kein Problem sein gleichzeitig mehrere Resultsets offen zu haben.
Sonst wäre ein komplexes Programm nicht machbar.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von Jan »

Hubert,

nein. Schau Dir mal in der Hilfe den SELECT (SQL) an. Das geht immer. Egal welche DBE.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

brandelh hat geschrieben: Mi, 20. Jun 2018 16:26 dazu musst du erstmal schreiben, mit was du auf SQL Dateien zugreifen willst !
native, direkt auf die LIBPQ.DLL
... soll es sogar direkte Unterstützung für das Browsen geben.
das "umschaufeln" der Daten in Array kostet Zeit und ist bei grossen Result Set dann langsam.
ich kann aber direkt in den Tuples des Result Set browsen und das mit einem Codeblock

Code: Alles auswählen

   for i := 1 to oPGResult:cols
      cField := oPGResult:fname(i-1)
      oBr:addColumn( MakeFieldBlock( oPGResult, cField ), , cField )
   next

Function MakeFieldBlock( o, c )
RETURN { || o:DataBlock( c ) }
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von brandelh »

ein Objekt ... oPGResult und code von Phil IDE ... ich vermute mal, dass dieses Objekt alles kapselt, aber musst du am Besten ausprobieren !
Gruß
Hubert
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: SQL Relation

Beitrag von Werner_Bayern »

AUGE_OHR hat geschrieben: Mi, 20. Jun 2018 15:47 das o:itemMarked feuert IMHO sobald ich auf einem Datensatz stehe aber dann ist das Browse evtl. noch nicht "Stable"

angenommen ich habe 10 Sätze und stehe auf dem 5th und betätige PgDn.
der DbSkipper baut also 11-15 auf und "merkt" das ich auf der Row 15 stehe -> o:itemMarked

wenn das nun auf ein anderes ALIAS geht werden 16-20 im 1st Browse nicht mehr sauber aufgebaut.
erst wenn alle 10 Zeilen vorhanden sind ("Stable") darf deshalb dann erst die Aktion durchgeführt werden
Nein:
The xbeBRW_ItemMarked event is created when a data row or a cell is highlighted in the browser.
Genau das macht er bei mir, er feuert genau 1x. Selbst ein Bildauf- oder ab erzeugt genau 1x den Event.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

Werner_Bayern hat geschrieben: Do, 21. Jun 2018 10:54 Genau das macht er bei mir, er feuert genau 1x. Selbst ein Bildauf- oder ab erzeugt genau 1x den Event.
es geht ja nicht darum wie oft o:itemMarked feuert sondern ob das Browse dann schon "Stable" ist.
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von Tom »

Ja, ist es.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von Tom »

Im Übrigen kannst Du XbpBrowse:StableBlock belegen, um auf Nummer Sicher zu gehen. Der Slot wird evaluiert, wenn die Anzeige im Browser stabil ist. ItemMarked und ItemSelected feuern aber sowieso nur, wenn das der Fall ist.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

Tom hat geschrieben: Fr, 22. Jun 2018 9:01 Im Übrigen kannst Du XbpBrowse:StableBlock belegen, um auf Nummer Sicher zu gehen.
genau das ist ja das was ich auch sage das man erst dann eine weiter Aktion ausführen sollte wenn er "Stable" ist.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von brandelh »

Wenn der Browser während des Aufbaus schon auf Events reagieren würde,
wäre das ein Fehler im Design 8)
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SQL Relation

Beitrag von Tom »

So isses. Im Normalfall muss man sich darum nicht kümmern.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: SQL Relation

Beitrag von AUGE_OHR »

zunächst einmal ist das XbpBrowse() KEIN Windows Control und das Design ... :roll:
des weiteren ist die Frage warum es wohl ein "Stable" bzw. "o:StableBlock" / "ForceStable" gibt :?:

---

unter Windows gibt es z.b. den Notify Event LBN_SELCHANGE bei eine Listbox.
dieser feuert "sofort" den Event sobald sich die Auswahl/Focus geändert hat.
da es unter Windows kein "Stable" gibt muss man sich überlegen wie/wann man den Notify Event "auswertet"...

nun kann ich ja mehrere Items markieren aber es soll erst dann eine Aktion erfolgen wenn ich fertig bin mit der "Auswahl". o:itemMarked ist also dafür gedacht wenn man mehrere Items "markiert" hat welche mit o:itemSelected abgerufen werden.

---

wenn ich jetzt also mehrere Items in einem Browse markiert habe wie soll ich mit o:itemMarked jetzt eine "Relation" anzeigen :^o es geht nur mit dem Item auf dem ich, nach dem der DbSkipper "fertig" ist, stehe also bei "Stable" -> o:Stableblock :!:

unabhängig davon ist es NICHT das Thema von diesen Thread ... [-X
ich werde vermutlich ein "echtes" Windows Control wie Listview verwenden.
gruss by OHR
Jimmy
Antworten