Scope auf variablen Index
Moderator: Moderatoren
- Jan
- Marvin
- Beiträge: 14658
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Scope auf variablen Index
Sorry, die Üerbrschrift ist etwas verquast. Ich wußte nicht, wie ich das Problem in ein paar wenige Worte zusammenfassen sollte.
Ich habe folgendes Problem: In einer dbf sollen alle Positionen eines Auftrages per Scope ausgefiltert werden, um sie in einem Browse anzuzeigen. Aber nur die Positionen, die aus einem bestimmten Lagerreich stammen. Alle Lagerstandorte in diesem Bereich sollen sortiert sein. Und in dem Browse sollen alle Positionen, die abgearbeitet worden sind, unten stehen.
Für den Index habe ich also drei Felder, die ich Variabel auswerten muß. Keine Ahnung, wie ich das anstellen soll...
Ich hab also erstmal mit zweien angefangen: Auftragsnummer und ist abgearbeitet Ja/Nein. Für die Auftragsnummer gibt es ein numerisches Feld, für das abgearbeitet nicht. Das lese ich aus einem numerischen Feld aus, in dem steht, welche Anzahl des Artikels in dieser Position noch kommissioniert werden muß. Steht der auf 0, dann ist die Position fertig.
Ich habe also mal einen Index gebaut: IIf(Empty(fehlmenge), "1", "0") + Var2Char(auftragsnummer). Sinn ist: Wenn die benötigte Anzahl abgeabreitet ist, ist die Fehlmenge 0. Und damit würde der Indexausdruck 1 werden, was im Index nach der 1 kommt, die für eine beliebige andere Fehlanzahl stehen würde. Und damit rutscht der Satz nach unten im Browse.
Jetzt habe ich aber folgendes Problem: Wenn ich auf einer Position stehe um sie abzuarbeiten, und einen oBrowse:refreshCurrent() oder :refreshAll() mache, dann springt der Satzzeiger der dbf auf EoF()! Wenn ich mir vorher den RecNo() merke, und nach dem refresh auf den Satz zurückspringe, habe ich logischer Weise einen Darstellungsfehler. Aber man versucht ja in seiner Verzweiflung manchmal die bescheuertsten Sachen ...
Ich hab sowas mit einem variablen Index übrigens schon früher mal gemacht. Da funktioniert das einwandfrei. Allerdings fliegen da alle Sätze mit der betreffenden Bedingung auch aus dem Browse-Scope raus.
Wo ist da mein Denkfehler?
Jan
Ich habe folgendes Problem: In einer dbf sollen alle Positionen eines Auftrages per Scope ausgefiltert werden, um sie in einem Browse anzuzeigen. Aber nur die Positionen, die aus einem bestimmten Lagerreich stammen. Alle Lagerstandorte in diesem Bereich sollen sortiert sein. Und in dem Browse sollen alle Positionen, die abgearbeitet worden sind, unten stehen.
Für den Index habe ich also drei Felder, die ich Variabel auswerten muß. Keine Ahnung, wie ich das anstellen soll...
Ich hab also erstmal mit zweien angefangen: Auftragsnummer und ist abgearbeitet Ja/Nein. Für die Auftragsnummer gibt es ein numerisches Feld, für das abgearbeitet nicht. Das lese ich aus einem numerischen Feld aus, in dem steht, welche Anzahl des Artikels in dieser Position noch kommissioniert werden muß. Steht der auf 0, dann ist die Position fertig.
Ich habe also mal einen Index gebaut: IIf(Empty(fehlmenge), "1", "0") + Var2Char(auftragsnummer). Sinn ist: Wenn die benötigte Anzahl abgeabreitet ist, ist die Fehlmenge 0. Und damit würde der Indexausdruck 1 werden, was im Index nach der 1 kommt, die für eine beliebige andere Fehlanzahl stehen würde. Und damit rutscht der Satz nach unten im Browse.
Jetzt habe ich aber folgendes Problem: Wenn ich auf einer Position stehe um sie abzuarbeiten, und einen oBrowse:refreshCurrent() oder :refreshAll() mache, dann springt der Satzzeiger der dbf auf EoF()! Wenn ich mir vorher den RecNo() merke, und nach dem refresh auf den Satz zurückspringe, habe ich logischer Weise einen Darstellungsfehler. Aber man versucht ja in seiner Verzweiflung manchmal die bescheuertsten Sachen ...
Ich hab sowas mit einem variablen Index übrigens schon früher mal gemacht. Da funktioniert das einwandfrei. Allerdings fliegen da alle Sätze mit der betreffenden Bedingung auch aus dem Browse-Scope raus.
Wo ist da mein Denkfehler?
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2827
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 13 Mal
Re: Scope auf variablen Index
Hallo, Jan -
den Indexbegriff würde ich zumindest so aufbauen, dass die Auftragsnummer als erstes im Index steht, damit Du den Scope darauf setzen kannst.
den Indexbegriff würde ich zumindest so aufbauen, dass die Auftragsnummer als erstes im Index steht, damit Du den Scope darauf setzen kannst.
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Jan
- Marvin
- Beiträge: 14658
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Georg,
den Scope kann ich ja auch so darauf setzen:Jan
den Scope kann ich ja auch so darauf setzen:
Code: Alles auswählen
komi->(DbSetScope(SCOPE_TOP , "0" + Var2Char(nAktAuftrag)))
komi->(DbSetScope(SCOPE_BOTTOM, "1" + Var2Char(nAktAuftrag)))
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2827
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 13 Mal
Re: Scope auf variablen Index
Hallo, Jan -
da liegt wohl auch das Problem ...
Dein Scope beginnt mit allen offenen Aufträgen, ab Auftrag 10:
0.0010
0.0011
0.0012
1.0001
1.0002
...
1.0010
Baust Du den Index anders auf, kannst Du es so machen:
Damit ist NUR der Auftrag nAktAuftrag im Scope. Und so hatte ich Deine Anforderung verstanden, dass nur die Positionen von nAktAuftrag angezeigt werden sollen.
da liegt wohl auch das Problem ...
Dein Scope beginnt mit allen offenen Aufträgen, ab Auftrag 10:
0.0010
0.0011
0.0012
1.0001
1.0002
...
1.0010
Baust Du den Index anders auf, kannst Du es so machen:
Code: Alles auswählen
komi->(DbSetScope(SCOPE_TOP ,Var2Char(nAktAuftrag) + "0"))
komi->(DbSetScope(SCOPE_BOTTOM,Var2Char(nAktAuftrag) + "1"))
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Jan
- Marvin
- Beiträge: 14658
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Ich bin im Moment etwas irritiert. Ich habe den Index mal umgebaut. Einfach ein anderes Feld benutzt statt der Variablen. Das Feld ist ein C1. Und da steht ein "A" drin, wenn noch nicht die benötigte Anzahl abgearbeitet wurde. Wenn das geschehen ist, wird da ein "B" reingeschrieben. Zusätzlich habe ich das, wie von Georg vorgeschlagen, an das Ende gesetzt.
Ich habe also jetzt z. B. einen Auftrag, der dann so aussieht:
1523427.0B
1523427.0B
1523427.0A
1523427.0A
1523427.0A
Warum zum Henker stehen die Positionen mit dem "B" am Ende vorne im Index???
Jan
Ich habe also jetzt z. B. einen Auftrag, der dann so aussieht:
1523427.0B
1523427.0B
1523427.0A
1523427.0A
1523427.0A
Warum zum Henker stehen die Positionen mit dem "B" am Ende vorne im Index???
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14658
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Ich bin einen gehörigen Schritt weiter!
Es funktioniert NICHT, wenn ich mit Var2Char(nAktAuftrag) arbeite. Es funktioniert, wenn ich mit Str(nAktAuftrag, 10, 1) arbeite.
Die einzige Erklärung, die ich dafür habe, ist, das es Auftragsnummern gibt die auf 0,0 stehen. Und ich damit einen Index aufbaue, der unterschiedliche Längen an Feldinhalten hat. Aber ob das wirklich so ist - keine Ahnung.
Jan
Es funktioniert NICHT, wenn ich mit Var2Char(nAktAuftrag) arbeite. Es funktioniert, wenn ich mit Str(nAktAuftrag, 10, 1) arbeite.
Die einzige Erklärung, die ich dafür habe, ist, das es Auftragsnummern gibt die auf 0,0 stehen. Und ich damit einen Index aufbaue, der unterschiedliche Längen an Feldinhalten hat. Aber ob das wirklich so ist - keine Ahnung.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Scope auf variablen Index
@Jan
vergiss den Scope, kopiere dir doch die Daten des Auftrags der bearbeitet werden soll in eine Temporäre Datei und bearbeite diese. So wird alles viel einfacher. Nach dem bearbeiten schreibst du die Sätze zurück. Natürlich muss noch eine Logik für neue und gelöschte Sätze dazu. Ich hab Aufträge mit 1-300 Positionen und eine Hauptdatei mit mehreren Millionen Einträgen es funktioniert einwandfrei.
Cu Carlo
vergiss den Scope, kopiere dir doch die Daten des Auftrags der bearbeitet werden soll in eine Temporäre Datei und bearbeite diese. So wird alles viel einfacher. Nach dem bearbeiten schreibst du die Sätze zurück. Natürlich muss noch eine Logik für neue und gelöschte Sätze dazu. Ich hab Aufträge mit 1-300 Positionen und eine Hauptdatei mit mehreren Millionen Einträgen es funktioniert einwandfrei.
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Scope auf variablen Index
Servus Ramses,
und was machst Du, wenn zwischenzeitlich ein anderer User im Netz denselben Auftrag bearbeiten will? Satzsperre ist ja nicht, machst Du das über einen Marker und sperrst den gleichzeitigen Zugriff auf denselben Auftrag?
und was machst Du, wenn zwischenzeitlich ein anderer User im Netz denselben Auftrag bearbeiten will? Satzsperre ist ja nicht, machst Du das über einen Marker und sperrst den gleichzeitigen Zugriff auf denselben Auftrag?
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope auf variablen Index
hi,
wie du ja erkannt hast fliegt der Satz, nach der Bearbeitung, aus dem Scope ... und der Index ändert sich.
meine Frage die ich gestellt hatte war "wie" der Index von dem 2nd Browse aussieht ?
um das zu verhindern würde ich beim 2nd Browse auf ein Array gehen.
wie du ja erkannt hast fliegt der Satz, nach der Bearbeitung, aus dem Scope ... und der Index ändert sich.
meine Frage die ich gestellt hatte war "wie" der Index von dem 2nd Browse aussieht ?
um das zu verhindern würde ich beim 2nd Browse auf ein Array gehen.
gruss by OHR
Jimmy
Jimmy
- Jan
- Marvin
- Beiträge: 14658
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Jimmy,
Du hast das leider nicht verstanden. Da fliegt garnichts aus dem Scope raus. Weder aus dem oberen noch aus dem unteren Browse. Und die falsche Darstellung kommt schon, sobald die Browses angezeigt werden. Da hab ich noch überhaupt nichts gemacht mit den Datensätzen.
Jan
Du hast das leider nicht verstanden. Da fliegt garnichts aus dem Scope raus. Weder aus dem oberen noch aus dem unteren Browse. Und die falsche Darstellung kommt schon, sobald die Browses angezeigt werden. Da hab ich noch überhaupt nichts gemacht mit den Datensätzen.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope auf variablen Index
Danke für deine Belehrung aber nicht ich habe das Problem sondern du ...Jan hat geschrieben:Du hast das leider nicht verstanden.
a.) mit VAR2CHAR(NumField) einen Index bauen zu wollen ist kompletter Unsinn ...
Code: Alles auswählen
PROCEDURE MAIN
LOCAL a := 12345.0
LOCAL b := 1234567.0
LOCAL c := 0.0
? LEN( VAR2CHAR(a) )
? LEN( VAR2CHAR(b) )
? LEN( VAR2CHAR(c) )
WAIT
RETURN
im unteren Browse sind die noch nicht abgearbeiteten Positionen die danach in den oberen Browse wandern, oder ?
nun mag es theoretisch mit 2 x DBF + Index in 2 Browse klappen ... bis du was an einem Datensatz änderst und damit auch den Index ...
Frage : öffnest du die 2nd DBF in der selben Workspace() mit anderem ALIAS oder im Thread ?
worauf ich raus will das nach einem RLOCK / UNLOCK / COMMIT / SKIP(oldNr) die Änderung im 2nd ALIAS "nicht sofort sichtbar" sind.
wenn das 2nd Browse in einem Thread läuft "könntest" du die andere Workspace() darüber "informieren" ( DBO_* Konstanten) das sich was getan hat.
leider stand mir unter Cl*pper solche Möglichkeiten nicht zur Verfügung und deshalb kam ich auf die Array Lösung für das 2nd (T)Browse.
gruss by OHR
Jimmy
Jimmy
- Jan
- Marvin
- Beiträge: 14658
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Jimmy,
noch einmal: Du hast es leider nicht verstanden. Da wechselt garnichts zwischen den Browses hin und her. Hab ich nie behauptet oder angedeutet. Ganz im Gegenteil.
Ich hab auch nie irgendwas von Threads gesagt. Ich arbeite ganz gerne damit, aber nicht hier, wo einfach in einem Dialog in zwei Browses die gleiche dbf (nur eben unterschiedlich gefiltert) angezeigt werden.
Das mit dem Var2Char() im Index hab ich im Übrigen schon geändert, dadurch ist ein anderes Problem weg. Aber noch nicht das, um das es in diesem Thread geht.
Jan
noch einmal: Du hast es leider nicht verstanden. Da wechselt garnichts zwischen den Browses hin und her. Hab ich nie behauptet oder angedeutet. Ganz im Gegenteil.
Ich hab auch nie irgendwas von Threads gesagt. Ich arbeite ganz gerne damit, aber nicht hier, wo einfach in einem Dialog in zwei Browses die gleiche dbf (nur eben unterschiedlich gefiltert) angezeigt werden.
Das mit dem Var2Char() im Index hab ich im Übrigen schon geändert, dadurch ist ein anderes Problem weg. Aber noch nicht das, um das es in diesem Thread geht.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
wenn du die eine DBF in 2 Workareas geöffnet hast und jeder Browser seinen Workbereich hat, dann sollte das ohne Probleme gehen.
wenn nicht, dann musst du das ändern.
wenn nicht, dann musst du das ändern.
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
aber oben steht "Anzeige" / Darstellung ...
da kann ich nur sagen "eine DBF, eine Workarea" und alle anzuzeigenden Datein in ein Array.
da kann ich nur sagen "eine DBF, eine Workarea" und alle anzuzeigenden Datein in ein Array.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2517
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Scope auf variablen Index
@werner
ja genau, ich habe eine Auftrags-Kopf und eine Auftrags-Pos DBF. Pro Auftrag gibts einen Kopfeintrag und beliebige Positionen. öffnet 1 Benutzer einen Auftrag zur Bearbeitung wird der Kopfrecord gesperrt.
Damit ist sichergestellt gleichzeitig nur 1 Anwender einen Auftrag bearbeiten kann.
Cu Carlo
ja genau, ich habe eine Auftrags-Kopf und eine Auftrags-Pos DBF. Pro Auftrag gibts einen Kopfeintrag und beliebige Positionen. öffnet 1 Benutzer einen Auftrag zur Bearbeitung wird der Kopfrecord gesperrt.
Damit ist sichergestellt gleichzeitig nur 1 Anwender einen Auftrag bearbeiten kann.
Cu Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope auf variablen Index
das Problem sind nicht die 2 x DBF mit verschieden ALIAS sondern das was (und wann ) bei einer Änderung mit dem Index passiertbrandelh hat geschrieben:wenn du die eine DBF in 2 Workareas geöffnet hast und jeder Browser seinen Workbereich hat, dann sollte das ohne Probleme gehen.
bei Verwendung von Thread hat man ja automatisch eine andere WorkspaceList() welche per "notify()" sich gegenseitig "informieren" können wenn "was passiert".
dem User ist es egal wie es technisch gelöst wird ... Hauptsache es funktioniert und ist stabil.Jan hat geschrieben:wo einfach in einem Dialog in zwei Browses die gleiche dbf (nur eben unterschiedlich gefiltert) angezeigt werden.
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Hallo, Jan.
Ich habe das Phänomen in Frankfurt ja kurz sehen können. Es sieht so aus, als kämen die Navigationscodeblöcke für das untere (abhängige) Browse nicht mit den Scope-Bedingungen zurecht, genauer mit der "unteren" Bedingung (SCOPE_BOTTOM). Die Frage ist, was passiert, wenn Du nur das untere Browse anzeigst, also einen Dialog ausbaust, der nur diesen Teil enthält, mit entsprechend festen Scope-Kriterien. Eine weitere Frage würde lauten, wie die Navigationscodeblöcke genau aussehen. Denkbar, dass einer davon mit falschen Daten hantiert. Eine dritte Frage lautet, was Du als Ergebnis bekommst, wenn Du Dir in einer einfachen DO WHILE-Schleife die Datensätze des falsch angezeigten Browses irgendwie ausgeben lässt.
Ich habe das Phänomen in Frankfurt ja kurz sehen können. Es sieht so aus, als kämen die Navigationscodeblöcke für das untere (abhängige) Browse nicht mit den Scope-Bedingungen zurecht, genauer mit der "unteren" Bedingung (SCOPE_BOTTOM). Die Frage ist, was passiert, wenn Du nur das untere Browse anzeigst, also einen Dialog ausbaust, der nur diesen Teil enthält, mit entsprechend festen Scope-Kriterien. Eine weitere Frage würde lauten, wie die Navigationscodeblöcke genau aussehen. Denkbar, dass einer davon mit falschen Daten hantiert. Eine dritte Frage lautet, was Du als Ergebnis bekommst, wenn Du Dir in einer einfachen DO WHILE-Schleife die Datensätze des falsch angezeigten Browses irgendwie ausgeben lässt.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
ICH verwechsle immer wieder mal den höchsten und niedrigsten Scope Wert (SCOPE_BOTTOM) ... hast du da was falsches angegeben ?
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14658
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Hallo Tom,
was Du immer alles so auf meinem Bildschirm siehst ... Da ist NSA ja ganrichts gegen
Der obere Browse hat in der Tat einen Scope mit verschiedenen TOP und BOTTOM-Werten. Der untere Browse dagegen einen BOTH. Ich hatte das vor der Tagung mal bei meinem Kunden getestet - wenn ich den oberen Browse auskommentiere, dann wird der untere absolut korrekt dargestellt. Ich habe aber auch alle Navigationscodeblöcke, Datalinks, usw. in beiden Browses kontroliert. Das ist alles korrekt.
Mir ist klar das ich da doch irgendwas übersehe. Denn irgendwoher kommt ja der Fehler. Und der muß meiner Meinung nach irgendwo bei meiner Konfiguration liegen.
Jan
was Du immer alles so auf meinem Bildschirm siehst ... Da ist NSA ja ganrichts gegen
Der obere Browse hat in der Tat einen Scope mit verschiedenen TOP und BOTTOM-Werten. Der untere Browse dagegen einen BOTH. Ich hatte das vor der Tagung mal bei meinem Kunden getestet - wenn ich den oberen Browse auskommentiere, dann wird der untere absolut korrekt dargestellt. Ich habe aber auch alle Navigationscodeblöcke, Datalinks, usw. in beiden Browses kontroliert. Das ist alles korrekt.
Mir ist klar das ich da doch irgendwas übersehe. Denn irgendwoher kommt ja der Fehler. Und der muß meiner Meinung nach irgendwo bei meiner Konfiguration liegen.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope auf variablen Index
hattest du nicht ein Demo für Alaska gemacht ?Jan hat geschrieben:Mir ist klar das ich da doch irgendwas übersehe. Denn irgendwoher kommt ja der Fehler. Und der muß meiner Meinung nach irgendwo bei meiner Konfiguration liegen.
wie wäre es wenn du das uploadest damit wir dir helfen können ...
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope auf variablen Index
Äh, Jan.
Du hast mir das gezeigt. Am Freitagnachmittag.
Es sah in meiner Erinnerung so aus, als würde das untere Browse um jeden Preis versuchen, die gleiche Anzahl Datensätze wie das obere anzuzeigen. Das bedeutet, dass sich die Datalinks der Spalten zwar in der richtigen Ergebnismenge bewegen, die Datenquelle des Browses jedoch eine falsche ist (oder eben die Navi-Codeblöcke nicht stimmen - oder, oder, oder). Nimm doch einfach mal die Scopes raus. Mach's mit einer kleinen Teiltabelle. Das sollte sich leicht finden lassen.
Wüsste ich's nicht besser, würde ich fragen: Warst Du eigentlich für eine verdammte Sekunde nüchtern?was Du immer alles so auf meinem Bildschirm siehst ... Da ist NSA ja ganrichts gegen
Du hast mir das gezeigt. Am Freitagnachmittag.
Es sah in meiner Erinnerung so aus, als würde das untere Browse um jeden Preis versuchen, die gleiche Anzahl Datensätze wie das obere anzuzeigen. Das bedeutet, dass sich die Datalinks der Spalten zwar in der richtigen Ergebnismenge bewegen, die Datenquelle des Browses jedoch eine falsche ist (oder eben die Navi-Codeblöcke nicht stimmen - oder, oder, oder). Nimm doch einfach mal die Scopes raus. Mach's mit einer kleinen Teiltabelle. Das sollte sich leicht finden lassen.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Scope auf variablen Index
ich habe es eben noch mal gelesen und muss noch mal nachfragen : du hast 1 x DBF und nicht 2 x DBF (egal ALIAS oder Thread) ???Jan hat geschrieben: wo einfach in einem Dialog in zwei Browses die gleiche dbf (nur eben unterschiedlich gefiltert) angezeigt werden.
du willst auf die selbe DBF 2 x mit Browse zugreifen ?
wenn du tatsächlich so etwas (verrücktes) konstruieren willst dann hatte ich es tatsächlich nicht verstanden ...
hm ... du hättest dann 2 x
Code: Alles auswählen
oBrowse:skipBlock := {|n| DbSkipper(n) }
nun "bewegst" du ihn im 1st Browse -> Skip +-1 -> Anzeige synchron ... und was macht das 2nd Browse ?
wenn du eine RELATION ( auf ein 2nd ALIAS ) hättest würde das ja eine automatische Reaktion der Datenbank durch die DBO erfolgen und nach ein o:RefreshAll() wäre dann auch die Anzeige synchron.
wenn das 2nd Browse nicht weiss das es nicht mehr im (Skipper)Scope ist ( die Abfrage > EOF() kommt erst danach ) dann bekommst du wahrscheinlich eine Fehlermeldung : Forcestable() ...
... und hab ich nun verstanden was du (verrücktest) machen willst ?
gruss by OHR
Jimmy
Jimmy