Tabellenzugriff ohne PK

10. Mai 2007 12:06

Hallo zusammen,

ich benötige bezüglich einer Veranschaulichung mal ein Beispiel wie ich auf eine Tabelle zugreifen kann und dort ein Feld auslese ohne aber den PK zu wissen.

Es existiert der Dataport1, welcher der Tabelle1 zugewießen ist. Beim Ausführen soll dieser Daten aus einer Textdatei importieren und in die Tabelle1 schreiben.

Tabelle1.Feldx = Wird durch den Import der Textdatei direkt gefüllt
Tabelle2.Feldy = Soll über die andere Tabelle gefüllt werden

Über Tabelle1.Feldx möchte ich jetzt auf die Tabelle2 zugreifen, da dieses Feld auch dort vorhanden ist, und auf das Tabelle2.Feld1, also den PK, zugreifen und den Wert dann in Tabelle2.Feldy schreiben.

Wie stell ich das am besten an ?

10. Mai 2007 14:05

PK

was meinst du?
Primary Key??
Gruß Mikka

10. Mai 2007 14:09

In der Regel ja ;-)

10. Mai 2007 14:12

Jupp. PK, PS, .. oder was es sonst noch so gibt ^^

10. Mai 2007 14:16

Ok,
das hilft mir weiter (..und ich dachte ich bin schreibfaul ;-) *fg*)

Timo hat ein Tool bereitgestellt im Downloadbereich:RecRef - GetBestKey

Vieleicht ist es das was du suchst?
Gruß Mikka

10. Mai 2007 14:24

Ich habe PK in der Akronyme - Liste mit aufgenommen.
(Somit ist zu ersehen, was gemeint ist!)
Falls ihr noch weitere kennt, die in diese Liste aufgenommen werden sollen, bitte im Forenbereich Klatsch & Trasch posten.
Gruß Mikka

10. Mai 2007 14:25

Na ja, schreibfaul bin ich auch nicht :) Ich dachte nur PK ist ne gängige Abkürzung. Was nutzt ihr denn hier oder schreibt ihr alles aus ? :)

Hab mir die Beschreibung des Tools mal angeguckt. Problem bei der Sache ist ich kann bzw. darf bzw. sollte den PK ;) nicht ändern. Vielleicht hast du mich auch falsch verstanden. Ich will nicht den Key wissen sondern den Inhalt des Feldes also den Wert. Ich muss irgendwie auf die Tabelle 2 zugreifen und dort den Inhalt des PKs auslesen. Ich habe gewisse Spalten die in beiden Tabellen auftauchen.

10. Mai 2007 14:39

PK ist mir schon geläufig,
allerdings war ich mir bei Deiner Frage nicht sicher ob du nur den Prim.Key (so schreibe ich meistens!) meinst oder die Sec.Key´s.
Die könnten evtl. auch gemeint sein, oder?

Zu beachten ist auch, das es einige hier im Forum gibt, die mit Datenbanken noch nicht so vertaut sind.
Für diese "Zielgruppe" es es natürlich besser verständlich wenn die Worte ausgeschrieben werden.
(Alternativ gibt es auch die Akronyme z.B. NSC oder MBSP).
Gruß Mikka

PS: Bitte verstehe "schreibfaul" nicht als Angriff gegen deine Person. Falls doch entschuldige ich mich für die Formulierung.
Zuletzt geändert von mikka am 10. Mai 2007 14:47, insgesamt 1-mal geändert.

10. Mai 2007 14:46

Ach Quatsch, ich fass das doch nicht als Angriff auf ^^
Ist doch alles in Butter. Du weisst was gemeint ist und ich hätte auch kein Problem damit gehabt es auszuschreiben ;)

10. Mai 2007 14:48

*klugscheiß*

PK und SK sind aber trotzdem recht gängige Abkürzungen im DB(=Datenbank ;-)Umfeld.

10. Mai 2007 15:29

Mikka hat geschrieben:Zu beachten ist auch, das es einige hier im Forum gibt, die mit Datenbanken noch nicht so vertaut sind.


@Natalie
:-P :-P :-P
*klugscheiß-zurück* *fg*
Ich meinte z.B. Schüler oder Studenten (..und Mikka, der den Wald nicht sieht), die zwar bereits Kontakt zu DB´s hatten.
Nur wenn man dich auf ohnehin Komplexe Vorgänge sich Konzentrieren muss, ist es einfacher verständliche Worte zu benuten.

Der AbküFi macht es nicht immer leichter (ausser für den der Schreibt!)

Genauso liebe ich unsere Manager die alles in Denglish machen müssen.
Oder gleich ohne weiteren Zusammenhang mitten im Text mit Englishen Floskeln anfangen

Zurück zum Toppic
@CBT
Ich hoffe du kommst mit dem Tool weiter?

Gruß Mikka

PS: AbküFi: Abkürzungsfimmel (sehr beliebt an Uni´s und bei der Bundeswehr) !

10. Mai 2007 15:38

Na ja ... Wie in meinem 2. Post geschrieben ...

Hab mir die Beschreibung des Tools mal angeguckt. Problem bei der Sache ist ich kann bzw. darf bzw. sollte den PK ;) nicht ändern. Vielleicht hast du mich auch falsch verstanden. Ich will nicht den Key wissen sondern den Inhalt des Feldes also den Wert. Ich muss irgendwie auf die Tabelle 2 zugreifen und dort den Inhalt des PKs auslesen. Ich habe gewisse Spalten die in beiden Tabellen auftauchen.

10. Mai 2007 15:49

Wenn ich dich richtig Verstanden habe, etwa so:
Variable vom Typ Record anlegen auf deine Tabelle2 Verweisen lassen.

Dann die entsprechenden Felder Filtern und ein FIND ausführen.
Nun kannst du aus dem Prim. Key Feld den Wert auslesen.
Code:
Tab2.SETRANGE(Tab2.FeldX,Tab1.FeldZ1);
Tab2.SETRANGE(Tab2.FeldY,Tab1.FeldZ2);
IF Tab2.FIND('-') THEN
  Tab1.FeldZ3 := Tab2.PrimKeyFeldInhalt;


Meist du so, oder habe ich es falsch Verstanden?
Wenn das Korrekt ist, beachte, das die Filterung eindeutige Datensäzte "hervorbringt"!
Gruß Mikka

10. Mai 2007 17:21

Ich glaube ich schreibe das ganze mal in Worten und nitt x und y, vielleicht versteh ich dann mehr ;)

Das ganze würde dann doch einfach wie folgt aussehen oder lieg ich da falsch ? Oo

Code:
recTabelle2.SETRANGE (recTabelle2.Objektnummer, recTabelle1.Objektnummer);
IF recTabelle2.FIND ('-') THEN
  recTabelle1.Erfassungsnummer := recTabelle2.PK;


Wenn ja wäre das ja einfacher als ich dachte :/

Mein Denkfehler war halt dass ich ja ein GET brauche um den Record zu füllen und mir die Daten zu holen, ich aber kein GET machen kann da ich ja genau dieses Feld haben will auf das ich den GET machen muss. Ich glaube ich verpeile immer noch WANN er WAS in den Record schreibt und wann nicht.

10. Mai 2007 19:27

CBT hat geschrieben:Mein Denkfehler war halt dass ich ja ein GET brauche um den Record zu füllen und mir die Daten zu holen, ich aber kein GET machen kann da ich ja genau dieses Feld haben will auf das ich den GET machen muss. Ich glaube ich verpeile immer noch WANN er WAS in den Record schreibt und wann nicht.


GET kann nur für PK- Felder verwendet werden,
- ignoriert gesetzte Filter,
- ist sehr schnell und findet immer höchstens einen Datensatz.

SETRANGE bzw. SETFILTER kann für alle Felder einer Tabelle verwendet werden,
- berücksichtigt alle vorher gesetzten Filterungen wenn diese nicht mit RESET oder SETRANGE (ohne Wert) entfernt wurden,
- kann als Ergebnis einen oder mehrere Datensätze enthalten (wobei die Performance bei Tabellen mit vielen Datensätzen stark von dem richtigen Sortierschlüssel abhängig ist)
die dann ggf. in einer REPEAT-UNTIL Schleife weiter analysiert werden können, wenn mehr als einer erwartet wird.

Wenn die Zuweisung auch nach Beenden des Dataports Bestand haben soll, muss für die geänderten Tabellen noch jeweils ein MODIFY folgen.

11. Mai 2007 08:38

Ich habe PK in der Akronyme - Liste mit aufgenommen

Es gibt 'ne "Akronyme - Liste"? Wo, hier im Forum? Dann hätt' ich u.U. auch ein paar zum Thema:

Idx = Index
CI = Clustered Index
NCI = Non-Clustered Index
FK = Foreign Key

*klugscheiß*

Darf ich mitspielen?

Es gibt genau genommen gar keine SK (Secondary Keys)! "Keys" sind per Definition "Einschränkungen" (wie z.B. der PK). SK sind keine Einschränkungen, sondern lediglich "Indexe" :twisted:

11. Mai 2007 08:43

stryk hat geschrieben:Es gibt genau genommen gar keine SK (Secondary Keys)! "Keys" sind per Definition "Einschränkungen" (wie z.B. der PK). SK sind keine Einschränkungen, sondern lediglich "Indexe" :twisted:


Mooooment mal.... Wenn wir die Navision-Welt verlassen, sind SKs nicht einfach irgendwelche Indizes, sondern weitere Schlüssel, die einen Datensatz ebenso eindeutig kennzeichnen wie der PK - sofern vorhanden.
http://de.wikipedia.org/wiki/Schl%C3%BC ... tenbank%29

11. Mai 2007 08:58

Natalie hat geschrieben:
stryk hat geschrieben:Es gibt genau genommen gar keine SK (Secondary Keys)! "Keys" sind per Definition "Einschränkungen" (wie z.B. der PK). SK sind keine Einschränkungen, sondern lediglich "Indexe" :twisted:


Mooooment mal.... Wenn wir die Navision-Welt verlassen, sind SKs nicht einfach irgendwelche Indizes, sondern weitere Schlüssel, die einen Datensatz ebenso eindeutig kennzeichnen wie der PK - sofern vorhanden.
http://de.wikipedia.org/wiki/Schl%C3%BC ... tenbank%29

<Klugscheisser-Modus>
Wenn wir hier schon am klugscheissen sind, dann will ich auch mal:
Rein technisch gesehen sind alle Schlüssel in Navision eindeutig, da an der PK an allen SK angehängt wird.
Im TableDesigner kann man das zwar nicht sehen, wenn man sich die Indizes auf dem SQL-Server anschaut, dann sieht man das auf den ersten Blick.
</Klugscheisser-Modus>

11. Mai 2007 09:23

stryk hat geschrieben:Es gibt 'ne "Akronyme - Liste"?

JA!
stryk hat geschrieben:Wo, hier im Forum?

wieder JA!
stryk hat geschrieben:Dann hätt' ich u.U. auch ein paar zum Thema:
Idx = Index
CI = Clustered Index
NCI = Non-Clustered Index
FK = Foreign Key

Dann geh doch mal mit der Maus über die Abkürzungen.... ;-)
stryk hat geschrieben:Darf ich mitspielen?

Nein, hier dürfen nur die mitspielen, die schon groß sind :mrgreen:, also grün oder rotbraun ;-)
Aber Ideen darf jeder anbringen, Ich habe Deine Vorschläge aufgenommen.

11. Mai 2007 09:29

Stryk hat geschrieben:Es gibt 'ne "Akronyme - Liste"? Wo, hier im Forum? Dann hätt' ich u.U. auch ein paar zum Thema:


Diese Liste ist für Forenmitglieder nicht ersichtlich!
Die Moderatoren nehmen aber gerne wünsche entgegen und ergänzen diese Liste.

@CBT
CBT hat geschrieben:Das ganze würde dann doch einfach wie folgt aussehen oder lieg ich da falsch ?

Nein, du liegst richtig.
Tröste dich, mir geht es manchmal auch so und ich Vermute anderen auch.
Gruß Mikka

16. Mai 2007 10:40

Hallo zusammen,

ihr habt ja interesannte Diskussionen hier :D

Ich hatte letzte Woche einen Unfall und war daher bis heute krank geschrieben. Werde mich aber jetzt der Sache mal annehmen und es mal ausprobieren und mich dann nochmal melden.

Schonmal vielen Dank an Alle.

@ Kowa : Bezüglich deinem Beispiel bzw. Erläuterung zu GET und SETRANGE o. SETFILTER. Folgendes ist mein Problem bzw. mein Denkfehler gewesen : Ein GET, wie der Name schon sagt, holt sich einen DS (Datensatz) und packt diesen in eine Recordvariable. So. Ein SETRANGE oder SETFILTER wendet auf eine Record Variable div. Filter an, um das Ergebnis einzuschränken. Laut meiner Logik müsste ich den Record aber vorher irgendwie füllen (Ähnlich dem GET) da ich doch sonst das SETRANGE bzw. SETFILTER auf einen leeren Record anwende. Daher wollte ich zuerst einen GET machen, welcher aber nicht ging da ich ja genau den PK benötigte. Das muss ich mir irgendwie nochmal zu Gemüte führen. Hoffe habe meine Denkweise bisschen klarer ausgedrüctk ^^

16. Mai 2007 11:20

Hi!
Ich hatte letzte Woche einen Unfall

Hoffe Du bist soweit OK!

Also:

Mittels GET liest man einen eindeutigen Datensatz über Primärschlüssel-Zugriff. z.B. Tabelle "Customer", PK: "No."

Customer.GET('00001');

Ein DS wird zurückgegeben.

SETRANGE und SETFILTER schränken eine Resultset (eine Mehrzahl von DS) ein. z.B.

Customer.SETRANGE(City, 'Nürnberg');

Diese Filterung alleine liefert keine DS!

Erst bei Ausführung eines lesenden Zugriffs, also via FIND, NEXT, etc. wird das Resultset zurückgegeben; je nach Methode wird dabei (i.d.R.) der DS-Zeiger auf den ersten oder letzten DS gesetzt:

Customer.FINDSET(FALSE, FALSE);

Hier werden alle 'Nürnberger' Kunden gefiltert, der Zeiger steht auf dem ersten DS.
D.h. es ist kein GET notwendig; anstattdessen wird der FIND verwendet.

Will man nur den ersten DS eines Resultsets verwenden, dann sollte die FINDFIRST Methode verwendet werden.

Gruß,
Jörg

16. Mai 2007 12:10

Ja mir gehts schon wieder einigermaßen besser, danke. Hatte mehrere Rückenwirbel ausgerenkt und muss die ganze Woche noch zur Strombehandlung zum Arzt und bekomme noch paar Spritzen. War am ersten Tag wirklich schlimm, aber mittlerweile gehts wieder :)

Zum Thema : Super :D Besten Dank für die Erläuterung. Jetzt ist mir die ganze Sache auch klarer geworden und ich versteh auch den Ablauf. Mit dem FIND ('-') sucht er sich ja dann den ersten.

BTW : Ich liebe dieses Board ;) Es gibt meiner Meinung nach keine vergleichbare Anlaufstelle in dem Bereich. Besten Dank.