RemObjects Data Abstract Feldnamen werde bei TDBEdit zur Auswahl nicht angeboten

[Kostas]

Hallo Zusammen,

RODA in der aktuellen Version 7.0.65.1067.

ich versuche mich in RoDa einzuarbeiten. Aktuell habe ich ein Testprojekt erzeugt mit dem Wizard "Server und Client mit LoginService!". Ich starte den Server. Zur Designtime versuche ich über den RemoteDataAdapter die Tabellen automatisch zu erzeugen über "Create Data Tables" Doch das gelingt mir nicht immer. Manchmal kommt der Login-Dialog manchmal jedoch nicht, dafür eine Fehlermeldung "no connection available" Wenn ich das Projekt in diesem Fall beende und neu starte, geht es meistens. Der Server ist übrigens auf der gleichen Maschine. Wenn ich es geschafft habe die Tabellen anzulegen, kann ich ein TDBGrid mit der passenden TDADataSource verbinden.
Wenn ich den Client starte sehe ich danach auch Daten, nachdem ich Daten angefordert habe.
In Designtime habe ich jedoch keine Möglichkeit die Felder im Grid von meiner Datenquelle abzuholen. Die Liste ist immer leer. Auch kann ich beim TDBEdit den Feldnamen aus dem DropDown Property Fields nicht auswählen. Ich vermute das hat was mit dem LoginService zu tun.

Hat jemand eine Idee?

Gruß Kostas

[Kostas]

Die Feldname abzufragen geht schon. Man muss nur per Rechtsklick auf die DAMemoDataTable
die Methode "Get Design-Tile Data" aufrufen. Dann werden die Feldname vom Server angefordert.

Die anderen Probleme hängen vermutlich mit der Firebird 1.5 und der RODA Version 7.0.66.1068
zusammen. Die mitgelieferte Firebird Datenbank PC-Trade ist für Firebird 2.5 da konnte ich die Probleme noch nicht nachstellen.

Gruß Kostas

[kretabiker]

Hallo Kostas,

wenn ich es deinem Text richtig entnehme, hast du für deine Services die Option "Session Requiered" gesetzt, richtig? Hast du auf dem Client-Datamodul die Komponente TDADesigntimeCall abgelegt, diese mit dem Loginservice und der richtigen Login-Methode verbunden und die Parameter der Methode gesetzt? Dann reicht es, nach jedem Serverneustart über diese Komponente eine Verbindung zum Server aufzubauen, so dass die Loginabfrage beim Abruf der Tabellen entfällt.

Eine andere Möglichkeit für die Fehlermeldung ist das Fehlen der Implementierung der Methode "BeforeAcquireConnection" im Service-Modul, in der der Connectionname aus der Session geholt wird. Sieht z.B. so aus:

Delphi-Quellcode:

procedure TISEPricing.DataAbstractServiceBeforeAcquireConnection(
  aSender: TObject; var aConnectionName: string);
begin
  aConnectionName := Session.Values[sess_ISEConnectionName]
end;

Funktioniert natürlich nur, wenn du in der Login-Methode auch den ConnectionName in die Session geschrieben hast. Das machst du?

Udo

[Kostas]

Hallo Udo,
habe ich natürlich alles nicht gemacht. Ich habe alles default gelassen so wie der Wizard es erzeugt hat. Über DADesigntimeCall habe ich über Doku Wiki nichts gefunden. Und schon
wieder ein weiteres puzzle...
Serverseitig habe ich nun DataService_Impl.RequiredSession auf false gesetzt.
Dabei habe ich auch ReturnFullSchema entdeckt weches auf false steht. Sollte ich das auf true setzen?

LoginService.Connectionname = MobileConnection ist gesetzt.

Ist "sess_ISEConnectionName" eine Kontante für den ConnectionName?

Delphi-Quellcode:

procedure TLoginService.LoginServiceLogin(Sender: TObject; aUserID,
  aPassword: Utf8String; out aUserInfo: UserInfo;
  var aLoginSuccessful: Boolean);
begin
  // This is where your Login logic should be implemented. A default implementation has been added
  // for you.

  // If you application does not require sending back a UserInfo structure, you can set
  // aUserInfo to nil, indtead of returning a new instance.

  // If you require a more complex UserInfo structure (i.e. MyCompanyUserInfo), simply add
  // a new struct to the file WindowsFormsServer1.RODL and set its ancestor to UserInfo. You will then
  // be able to marshal your new custom class back to the client by reassigning the aEA.UserInfo property.

  // myInfo = new MyCompanyUserInfo();
  // myInfo.City = "London";
  // myInfo.Address = "213 Smith Road";
  // myInfo.Age = 32;
  // aUserInfo = myInfo;

  aLoginSuccessful := aUserID = aPassword;

  if aLoginSuccessful then begin
    aUserInfo := UserInfo.Create;
    aUserInfo.SessionID := UTF8String(GuidToAnsiString(ClientID));
    aUserInfo.UserID := aUserID;

    Session['UserID'] := aUserID;
  end
  else begin
    DestroySession;
  end;
end;

Gruß Kostas

[kretabiker]

*kopfkratz*Also, es ist schon ne ganze Weile her, dass ich den Wizzard eingesetzt habe, von daher weiß ich gerade nicht, was da alles so automatisch gesetzt wird...

Bei mir werden beim Login die ConnectionNames als Parameter mit übergeben, da sich ein User durchaus an unterschiedlichen Datenbanken anmelden können soll, z.B. per Auswahl aus einer Combobox im Logindialog des Clients. Diese Angaben werden dann in der Login-Methode auf dem Server in die Session geschrieben, wie in deinem Beispiel mit der UserID, also z.B. Session[sess_ISECONNECTIONNAME] = <als Parameter übergebener ConnectionName der Datenbank ISE> - natürlich erst, nachdem geprüft wurde, ob der User überhaupt auf die Connection zugreifen darf... sess_ISECONNECTIONNAME ist als eine Konstante im Server definiert/hinterlegt. Den entsprechenden Wert lese ich wie gezeigt in BeforeAcquireConnection aus - dann paßt das auch mit der Connection, wenn sich die Bedingungen ändern (Testserver, lokaler Server, Produktionsserver - alles unterschiedliche Connections).

Du solltest auf jeden Fall von vornherein den Wert für RequireSession wieder in allen Services ausser dem LoginServe auf True stellen, um Sicherheit im System zu haben - später vergißt man es nur (ich zumindest).

Die Verwendung der TDADesigntimeCall ist denkbar einfach, aber hilfreich in Verbindung mit session-gesicherten Servern:

- Falls noch nicht vorhanden: Eine TRORemoteService-Komponente für den Login-Service auf das Client-Datenmodul ziehen und mit Channel und Message-Komponenten verbinden. Danach den Servicenamen auf den LoginService setzen
- TDADesigntimeCall-Komponente auf das Datenmodule ziehen und mit der LoginService-TRORemoteService-Komponente verbinden
- In der Komponente dann das Property MethodName auf die Login-Methode, die du verwenden möchtest/mußt, stellen
- In der Auflistung Params werden dann die Parameter der Login-Methode gezeigt, die du dann mit Werten vorbelegen kannst, also UserName und Spaßwort, vielleicht auch die ConnectionNames usw., welche du während der Entwicklung verwenden möchtest.

Fertig.

Wenn du dann auf die Komponente (bei laufendem Server, natürlich) doppelklickst oder erst per rechter Maustaste das Kontextmenü aurufst und da MakeCall anklickst, meldet sich die Komponente mit den eingegebenen Daten beim Server an und stellt im Erfolgsfall die Informationen durch ein bisserl Magic im Hintergrund allen anderen RODA-Komponenten zur Verfügung - solange, bis der Server neu gestartet wird, dann muss der Call erneut ausgeführt werden. Ist als eine echte Arbeitserleichterung gedacht, sonst kommt der Login-Dialog alle naslang hoch. Übrigens: Wenn beim Ausführen des Calls trotzdem der Login-Dialog angezeigt wird, ist das ein untrügliches Zeichen dafür, dass mit deinen hinterlegten Daten was nicht stimmt - das Login ist dann fehlgeschlagen.