Zugriff auf Perforce-Metadaten mit ODBC: Datenformatproblem?

[StTüff]

Hallo!

Ich beschäftige mich momentan mit dem Zugriff auf die Metadaten von Perforce (Software Configuration Management System).
Perforce bietet zum Zugriff eine ODBC-Schnittstelle.
Der Zugriff mit z.B. Excel funktioniert problemlos. Als Beispiel nehme ich mal die Tabelle "users".

Hier liefert Excel:

Zitat:

user; email; fullname; updated; accessed;
Test1; [e-mail]; Max Musterman; 03.07.2007 17:52; 03.07.2007 17:52;
Test2; [e-mail]; Mia Musterfrau; 03.07.2007 14:59; 24.07.2007 18:07;

Da das so gut funktioniert, dachte ich mir, mach ich mal einen Metadatenviewer unter Delphi:
- Neu Anwendung
- dbgrid, datasource und adotable auf's Formular und alles schön verbunden.
- Connectionstring zusammengeklickt und Tabelle gewählt => Verbindung funktioniert

Im DBGrid wird jetzt folgendes angezeigt:

Zitat:

user; email; fullname; updated; accessed;
(BYTE); (BYTE); (BYTE); 03.07.2007 17:52; 03.07.2007 17:52;
(BYTE); (BYTE); (BYTE); 03.07.2007 14:59; 24.07.2007 18:07;

OK. DBGrid kann wohl das Format der Strings nicht direkt darstellen. Also habe ich mir gedacht: Mal schauen was da ankommt:

Delphi-Quellcode:

DataSource1.DataSet.FieldByName('user').AsString

Tja, nun sehe ich im Debugger '0'-Einträge: ... #0,#0 usw.
Nullen kann ich nicht wirklich in einen String konvertieren.

In der Perforcedokumentation steht als "Data Type" für diese Felder VARCHAR(254).

Mache ich hier beim Zugriff etwas falsch? Warum geht es mit Excel und mit Delphi nicht?
Ist es ein Formatproblem (unicode)?

Ich habe leider keinen Ansatzpunkt. Es wäre schön, wenn mir jemand einen Tip geben könnte oder einen Link zu einem ähnlichen Thema.

Veilen Dank und schönen Tag!

StTüff

[StTüff]

Hallo!

:gruebel: Ich bin mir nicht ganz sicher, wie ich die nicht ganz so rege beteiligung an diesem Thread werten soll.
Da gibt es mehrere Möglichkeiten:
- Die Antwort ist so banal, dass jeder denkt: "Da soll der mal selber drauf kommen".
- Ich habe die Fragestellung nicht richtig/ausreichend formuliert und das Problem wird nicht klar.
- Das Problem liegt an Perforce und damit kennt sich keiner aus.
oder
- Es kennt tatsächlich keiner eine möglich Lösung.

Ich wäre über Eure Beteiligung sehr dankbar, auch wenn Ihr nur einen Hinweis (und nicht die endgültige Lösung) habt. :wink:

Gruß und ansonsten schon mal schönes Wochenende,

StTüff

[marabu]

Hallo Stephan,

ich kann die Users problemlos auslesen.

Freundliche Grüße

[StTüff]

Hallo Marabu!

Danke für Deine Hilfe. Kannst Du noch ein wenig mehr dazu sagen, was Du gemacht hast?
Ich vermute, dass Du keine Perforceinstallation hast, oder? Du hast also vermutlich eine Datenbankdatei zum Testen erzeugt, die den angegebenen Datentyp enthält (die UDL-Datei war übrigens leider nicht mit dabei).
Ist das soweit korrekt?

Mit dieser Erkentnnis kann man dann eigentlich ausschließen, dass es am Datentyp liegt. Es muss also noch eine andere Besonderheit geben.

Anbei habe ich mal mein Beispiel angehängt. Dieses funktioniert aber natürlich nur in Verbindung mit Perforce und der eingerichteten Reporterweiterung (Benutzer-DSN wie im Screenshot konfiguriert).

Vielleicht hat ja jemand eine Perforceinstallation und kann das mal testen. Vielleicht erkennt auch jemand auf Grund der Einstellungen einen Fehler?!

Gruß und vielen Dank,

StTüff

[marabu]

Hallo Stephan,

ich hatte mir die aktuelle Perforce Trial nebst Reporting von der Hersteller-Seite gezogen und eine Standardinstallation durchgeführt.

Ich hatte die UDL-Datei durch ein Aktivieren der Connection in einen String verwandelt, aber wohl schon vorher das Demo-Projekt gepackt, ich Schussel. Anbei die UDL-Datei. Ich hatte kein Password verwendet und der User muss natürlich auch angepasst werden.

Schon beim Öffnen deines Projektes P4COMTEST sehe ich die Daten im Grid. Nach zwei Anpassungen am Quelltext (eine Methode und eine Funktion ohne Implementierung entfernt) lässt sich das Projekt bei mir übersetzen und ausführen. Keine Probleme.

Freundliche Grüße

[StTüff]

Hallo!

Bedeutet das, dass bei Dir auch mein Projekt so läuft, dass Du die Daten (also auch die Strings) angezeigt bekommst?
:freak:

Das würde mich völlig in Verzweiflung stürzen....
Dann gäbe es nur noch 2 Möglichkeiten:
1. Bei meinem Delphi ist was anders, oder
2. Dein Server läuft nicht im internationalised mode und meiner tut das vermutlich (muss ich zur Sicherheit noch mal prüfen). Ich bin diesbezüglich auch mit dem Support von Perforce in Kontakt. Mal sehen, ob ich herausbekomme, ob es ein "unicode-Problem" sein kann.

Auf jeden Fall vielen Dank für Deine Bemühungen!

Ich melde mich wieder....

StTüff

[shmia]

In manchen Fällen wird der Datentyp nicht korrekt durch die Treiberschichten bis nach oben in die Delphi VCL durchgereicht.
Statt ftString kommt ftBytes oder ftVarBytes an.
Das (Standard-)DBGrid von Delphi ist nicht in der Lage, diesen Datentyp anzuzeigen.
Dem lässt sich aber abhelfen; siehe Code-Library:
http://www.delphipraxis.net/internal...ct.php?t=46363

[StTüff]

Hallo Marabu!

Ich habe bei Deinem Projekt mal den Connectionstring gegen den ausgetauscht den ich verwende:

Code:

Provider=MSDASQL.1;Persist Security Info=False;User ID=sbaur;Data Source=Perforce;
Extended Properties="DSN=Perforce;UID=sbaur;"

Leider wird dann in Deinem Projekt auch kein username usw. angezeigt (Anzeige im Grid immer "(BYTE)") und im String stehen lauter '#0'(vemutlich 254?)).

Hallo Shima!

Deinem Tipp bin ich auch mal nachgegeangen und habe folgendes versucht:

Delphi-Quellcode:

Edit1.text:=HexStringToStr(DataSource1.DataSet.FieldByName('user').AsString);

Leider funktioniert auch das nicht. Vermutlich sind die Daten an der Stelle schon verloren (wie gesagt es sind lauter '#0'; siehe auch Screenshot anbei).

Es ist zum Verrückt werden :wall:

Vielleicht hilft mir der Perforce-Support weiter. Wenn Euch noch was einfällt....

Gruß vielen Dank,

StTüff

[StTüff]

... ach ja, Marabu: Kannst Du bitte noch die UDL-Datei hochladen, ich vermute, dass hast Du vergessen.

Vielen Dank!

StTüff

[marabu]

Guten Morgen,

hier die UDL-Datei. Bin gestern darüber gestolpert, dass die DP UDL-Dateien nicht mag. Als ODBC-DSN verwende ich den bei der Installtion bereit gestellten. Außer UserID und Password (bei mir leer) habe ich keine Angaben gemacht. Insbesondere setze ich keine Extended Properties.

Vielleicht hast du gar keinen Konfigurationsfehler im Connection String gemacht. Wie Andreas schon geschrieben hat deutet die Anzeige (BYTE) darauf hin, dass der Treiber das VARCHAR-Feld nicht korrekt erkannt hat. Als Feldgröße solltest du den Wert 4 vorfinden. Du solltest mal mit einem anderen ODBC-Treiber testen. Meiner ist Version 2007.01.12.122.

Freundliche Grüße

[StTüff]

Hallo!

Vielen Dank für die Info und die UDL! Ich werde weiter Testen.
Was mich verwundert, ist, dass es mit Excel geht. Wenn es am ODBC-Treiber liegen würde, dann müsste das Problem doch eigentlich auch mit Excel auftreten, oder? Meine Treiberversion ist gleich wie Deine.

...noch eine Info, die ich geprüft habe:

Der Server läuft nicht im "Unicode-Mode". Das kann also auch nicht der Grund sein.

Gruß,

StTüff

[StTüff]

Hallo!

Ich habe jetzt noch was ganz anderes gemacht:
=> Rave Reports 6.5 BE
Auch hier tritt das Problem auf.
Ich habe es versucht mit
a) einer ADO-Verbindung: lauter Rechtecke (ungültige Zeichen?)
b) über die BDE: es wird (invalid) angezeigt
Die übrigen Felder (also keine Strings) werden (wie beim Delphi-Testprojekt) korrekt angezeigt.

Beim Reporting, dass von Perforce geliefert wird, wird (wenn ich das richtig einschätze) Crystal Reports verwendet. Hier werden alle Felder korrekt angezeigt.

Wenn ich jetzt noch wüsste, was mir das nun sagt....

Auf jeden Fall liegt es nicht am Connection-String nicht am DBGrid und vermutlich auch nicht an anderen Komponenten, bzw. der zugehörigen Konfiguration, die für die Verbindung eingesetzt wurden.

Jetzt stellt sich die Frage:
Was ist bei Rave Reports gleich wie bei Delphi und was ist unterschiedlich zu Excel und Crystal Reports....

Fällt Euch da was ein?

StTüff

[shmia]

Neben ODBC ist ja auch ADO im Spiel.
Welche MDAC (Microsoft Data Access Components) Version ist denn bei dir installiert ?
Du kannst dazu den MDAC Component Checker verwenden.
http://msdn2.microsoft.com/de-de/data/aa937730.aspx

[StTüff]

=> MDAC 2.8 SP1

Allerdings sind ein paar Dateien aktueller, als die in der Release-Version. Könnte das ein Problem sein???

Gruß,

StTüff

[shmia]

Zitat:

Zitat von StTüff

=> MDAC 2.8 SP1
Allerdings sind ein paar Dateien aktueller, als die in der Release-Version. Könnte das ein Problem sein???

Ich denke nicht bzw. schwer zu sagen. :gruebel:
Hättest du z.B. MDAC 2.6 auf dem Rechner, hätte ich dir geraten auf MDAC 2.8 SP1 upzudaten.

[StTüff]

So, jetzt habe ich noch den SQL Explorer (\Borland\BDS\4.0\Bin\dbexplor.exe) ausgepackt. Auch dieser zeigt die besagten Felder nicht an. Zusätzlich ist mir noch aufgefallen, dass ich einen Datenbank-Engine-Fehler (BDE-Fehler 8712 "Objekt nicht gefunden") bekomme, sobald ich bei einer Tabelle auf "Fields" klicke.

Könnte es sein, dass hier Felddefinitionen fehlen und es deshalb zu dem Problem kommt?

Marabu: Bei Dir funktioniert der Zugriff (wenn ich das richtig verstanden habe) ja. Könntest Du vielleicht auch mal mit dem SQL-Explorer probieren, was Dir bei "Fields" angezeigt wird (und mir vielleicht einen Screenshot schicken)?

Der Support hat bisher auch noch keine Spur. Mal sehen, ob wir das noch gelöst bekommen....

Gruß und noch mal vielen Dank für die Hilfe,

StTüff

[marabu]

Hallo,

beim Zugriff über die BDE kommt auch bei mir der Fehler 8712, aber das liegt vermutlich an der Implementierung des Perforce ODBC Drivers. Der ist vielleicht nur soweit ausgebaut worden, dass er die Tests mit CR besteht.

Ich erinnere mich noch an die schwierige Geburt des Easysoft ODBC Treibers für Interbase Open Edition. Insofern würden mich glitches im Perforce Treiber nicht sonderlich verwundern. Wenn du kannst, dann solltest du mal einen ODBC-Client verwenden, um den Umweg über BDE oder ADO zu eliminieren.

Freundliche Grüße

[StTüff]

Hallo!

Ich habe von Softvector.com die Trial-Version vom ODBC-Explorer heruntergeladen. Dieser zeigt die Daten korrekt an. Leider kann ich die ODBC DAC-Komponenten vom gleichen Hersteller nicht unter Delphi 2006 installieren (das hätte die Lösung sein können).

Hast Du mir noch einen Tip, welche Komponenten oder Möglichkeiten es noch gibt, direkt über ODBC auf die Datenbank zuzugreifen.

Gruß und vielen Dank,

StTüff

[marabu]

Hallo,

vielleicht helfen dir diese beiden Links weiter:

MODBC Page
ODBC Components ...

Freundliche Grüße

[StTüff]

Danke!
Bei mODBC kämpfe ich auch gerade mit der Installation unter D2006. Ich melde mich wieder...

StTüff

[StTüff]

OK! Nun funktionieren die Strings, dafür die anderen Felder nicht mehr....
Da ich hier aber den Quellcode habe, kann ich mal ein wenig tiefer schauen.

Nun gehe ich aber Volleyball spielen und verscheibe das auf morgen...

Gruß und schönen Tag noch!

StTüff

[StTüff]

Hallo!

Melde Erfolg! :hello:

Mit mODBC geht es jetzt. Ich hatte bei den Anpassungen der Komponente (damit ich diese unter D2006 compilieren konnte) noch einen kleinen Fehler gemacht.

Jetzt scheint es zu gehen.

Schlussfolgerung: Beim Perforce ODBC-Treiber scheint es noch Unzulänglichkeiten zu geben, die beim Umweg über ADO oder die BDE zum Problem werden (stimmt doch so, oder?). Zum Glück geht es aber mit mODBC, was zwar den Treiber nicht besser macht, aber mein Problem löst.

Vielen Dank für Eure Unterstützung!
:cheers:

Gruß,

StTüff