Prozedur zur Weiterverarbeitung der Daten in TIMPORT

[miboe]

Hallo,

ich befasse mich gerade mit der Universellen Importschnittstelle und finde das MOdul an sich ja echt Klasse. Ich habe aber ein kleines Problem, wahrscheinlich ein Verständnis-Problem:

Wenn man die Prozedur auswählen will zur Weiterverarbeitung, dann kommt ein Auswahldialog, der eine ganze Bank von Prozeduren anbietet, in welchem aber meine eigenen Prozeduren für die Weiterverarbeitung nicht angeboten werden.

Kann ich deren Namen einfach händisch eintippen, oder muß ich die Prozedur ähnlich dem Einlesen von UPGLB... und Tabellen im Admin irgendwo "anmelden"

Gruß
Michael

[SYN14]

Hallo miboe,

für die Anzeige der Prozedurliste ist die Prozedur P_BJOB_IBPROC_AUSWAHL verantwortlich:

Code: Alles auswählen

  /* Auswahl an IB-Proceduren, die ohne Ausgabe laufen können über Job
     abgearbeitet werden wird in frmv_bjob verwendet */

  FOR SELECT A.RDB$PROCEDURE_NAME
  FROM RDB$PROCEDURES A
  WHERE A.RDB$PROCEDURE_NAME LIKE 'P_%' AND
        A.RDB$PROCEDURE_NAME NOT IN (SELECT RDB$PROCEDURE_NAME
                                     FROM RDB$PROCEDURE_PARAMETERS
                                     WHERE RDB$PROCEDURE_NAME = A.RDB$PROCEDURE_NAME AND
                                           RDB$PARAMETER_TYPE = 1)
  ORDER BY A.RDB$PROCEDURE_NAME

Also werden nur Prozeduren angezeigt, die keine Rückgabeparameter haben und mit "P_" beginnen.

Ansonsten können Sie den Prozedurnamen auch händisch eintragen.

mfg SYN14

[miboe]

Danke ... hat funktioniert.

Gibt es eine Möglichkeit, außer den Universalvariablen, die in der Maske gegeben sind, auch Eingaben vom User abzufragen?

Mir ist nach Betrachtung der beiden OnClick-Scripte nur der Weg eingefallen, den Inhalt der Variable sProcParam, darauf hin zu prüfen, ob er ein gewisses Schlüsselwort enthält (z.B. :Userabfrage). Wenn dieses gefunden wird, soll das Script eine je nach Import angepaßte Abfrage starten, die dann den gewünschten Wert vom User übernimmt und den Schlüsselbegriff durch den Eingabewert ersetzt. Erst danach wird dann die UNIVERSALIMPORT ... gestartet. Das wird aber bei mehr als einem Input-Parameter der vom User eingegeben werden soll mehr als nur umständlich. Und normalerweise sollten für die Normalanwender in der BIMPKONF ja alle Rechte außer SELECT abgeschaltet sein. Eine Bearbeitung des Feldes PROC_PARAM wäre somit auch nicht machbar.

Wäre es denn nicht sinnvoll, die beiden UNIVERSAL... Routinen schon von Hause aus, mit dieser Intelligenz zu versehen. Ich stelle mir halt sowas vor wie bei den Statistiken. Dort ist es ja auch so, daß wenn in der SQL-Abfrage eine Variable :BAUF_ID (o.ä.) drin steht nach KLick auf Start zuerst alle Variablen abgefragt werden.

Gruß
Michael

[SYN14]

Hallo,

für wiederkehrende Importe ist es sinnvoll, diesen Vorgang in ein Utility zu "verpacken". Das hat den Vorteil, dass die folgenden Skript-Funktionen verwendet werden können bzw. können in dem Utility Daten vom Benutzer abfragen. Ich hoffe, dass die folgenden Definitionen ausreichen.

Code: Alles auswählen

UNIVERSALIMPORT(BIMPKONF.ID : integer)
   Universeller Datenimport für Excel, TXT, CSV etc.
   Daten werden in eine Tabelle TIMPORT geschrieben. Auf diese Daten
   kann dann die Auswertung oder Verarbeitung geschehen. 

UNIVERSALPROC(Procedurename, Parameter : string; bEingabe : boolean) : boolean;
   Führt eine Procedure aus. Der Parameter bEingabe besagt, ob
   Parameter, die nicht automatisch gesetzt werden können, abgefragt 
   werden sollen. Rückgabe bei erfolgreicher Ausführung ist True.

Dabei handelt es sich um die selben Routinen, die auch in der Importmaske verwendet werden.

Wichtig für Ihre Frage ist dann der Parameter bEingabe, der alle nicht gesetzten Parameter abfragt. Dies würde ich, wie schon gesagt, etwas eleganter über ein Utility lösen, in das der Benutzer die Parameter eingeben kann.

mfg SYN14

[miboe]

Hallo Syn14,

vielen Dank für die Info.

Ich werde dann für uns hier im Haus die Maske FRMV_BIMPKONF derart modifizieren, dass es nur noch den Import mit direkter Verarbeitung gibt ... alles andere macht bei uns keinen Sinn.

Die Schaltfläche "Daten Importieren" werde ich dann für die Konfigurationen wo das notwendig ist (sind nur max. 2-3) um entsprechende Skriptfunktionalitäten zur Parameterabfrage erweitern. Auf die Art braucht der User nicht in dem Datensatz rumzubiegen, wobei ich mich nämlich auf Dauer nicht wohl fühlen würde. Das würde dann nämlich bestimmt dazu führen, daß alle drei Tage einer anruft und sich beschwert, daß wieder irgendein Import nicht läuft

Viele Grüße
Michael

[miboe]

Planänderung ... klarer Fall von erst komplett zu Ende denken und denn schreiben

Ich werde das ganze doch in der entsprechenden Zielmaske als Utility einbinden. Beim zweiten Lesen ihrer Antwort und meiner drunter ist dann doch der Groschen in die andere Richtung gekippt

Danke
Michael

[miboe]

Oh Mann, was ist denn nu los ... schon wieder zu schnell!

Ich gehe mal davon aus, daß für den Fall, daß man die Parameter der Prozedur nochmal vom User abfragen will, in BIMPKONF natürlich der Sofortstart auf "NEIN" stehen muß, oder?

Gruß
Michael

[SYN14]

Bei einem Utility ist es so, dass die Prozedur aus der Maske Universalimport völlig ignoriert wird. Das Feld Sofortstart ist nur relevant, wenn Sie direkt über diese Maske importieren wollen.

Das Utility sollte vom Ablauf her so aussehen:
1. Parameter vom Benutzer holen
2. UNIVERSALIMPORT ausführen (damit werden die Daten in die Importtabelle eingelesen)
3. UNIVERSALPROC ausführen, damit die importierten Daten verarbeitet werden können; mit den entsprechenden Parametern vom Benutzer
4. Fertig

[miboe]

Das hätte ich ja dann sogar instinktiv richtig gemacht ... auch wenn heute kein guter Tag zum programmieren war.

Danke nochmal für die Bestätigung und Gruß
Michael

[miboe]

Ich muß da noch mal drauf rumreiten ...

Ich bin letzte Woche darüber gestolpert, daß bei dem genannten Verfahren zum Aufrufen aus einem Utility, also

Code: Alles auswählen

UNIVERALIMPORT(id);
UNIVERSALPROC(sProcName, sProcParam, 0);

das Programm genau dann ins Debug-Fenster rennt und den Import nicht macht, wenn man den Sofortstart auf "J" stellt. Erst wenn ich den Sofortstart auf "N" stelle, läuft das Utility wieder sauber.

Außerdem hatte ich das Gefühl, daß die Befehle UNIVERSAL... nur vom Sysdba ausführt werden können. Wenn man sich als "normaler" User anmeldet, der sowohl auf das Utility als auch auf die BIMPKONF Zugriff hat, landet man auch wieder im Debug-Fenster unabhängig von der Sofortstart Einstellung. Und auch dann, wenn es beim Sysdba funktioniert hat. Ich werde nochmal prüfen, ob der GRANT EXECUTE auf die mit UNIVERSALPROC aufgerufene Prozedur auch auf "Public" gesetzt ist, und mich nochmal melden, wenn ich's nicht in den Griff kriege.

Als Sysdba funktioniert alles sauber, deswegen soweit schonmal Danke für die Hilfe

Gruß
Michael

[SYN14]

Die über UNIVERSALPROC ausgeführte Prozedur muss, damit der Import von einem anderen Benutzer als SYSDBA durchgeführt werden kann, über PUBLIC-Rechte verfügen.

Code: Alles auswählen

GRANT EXECUTE ON PROCEDURE MEINPROZEDURNAME TO "PUBLIC";

mfg SYN14

[miboe]

Ich weiß, das konnte ich beim Testen aber nicht nachschauen, da auf dem Rechner kein IBexpert war ... ich bin nicht mehr bei der Firma, auch wenn ich noch von "wir" und "uns" schreibe. Deswegen habe ich derzeit immer in bißchen Zeitversatz was den nächsten Test anbelangt. Und die Prüfung mit dem "Public" kenne ich das Ergebnis noch nicht.

Aber wie gesagt: Ich habe es auch geschafft, es mit dem Sofortstart so hinzubiegen, daß auch der Sysdba ins Debug-Fenster geschickt wurde.

Gruß
Michael

[SYN14]

Es ist schwer zu beurteilen, warum es hier zu einem Fehler kommt. Es kann sein, dass die Importprozedur einen Fehler erzeugt oder dass beim Import etwas schief läuft oder, oder, oder.

Nachvollziehen kann man das nur, wenn man die Schritte einzeln durchführt. Datenimport, dann Prozedur ausführen. Und das am Besten mit IBExpert.

[miboe]

So es hat etwas gedauert, aber da bin ich wieder

Wir haben jetzt mal den Skript des Utility-Formulars mit "Schrittzählern" ausgestattet und dadurch festgestellt, daß das ganze schon innerhalb des Aufruf der UNIVERSALIMPORT scheitert ...
Wenn der User (auch der SYSDBA!) das Utility ausführt, werden alle Prüfungen und Abfragen des Maskenskriptes sauber ausgeführt, dann wird die UNIVERSALIMPORT gestartet, wobei das Programm auch den Datensatz aus der BIMPKONF korrekt auswertet, er greift nämlich auf die richtige Excel-Datei zu. Wie sich das gehört kommt dann der Abfragedialog, welches der Tabellenblätter man importierten will. Wir wählen dann das oberste Blatt aus und bestätigen mit OK. Danach kommt unmittelbar und ohne große Verzögerung das Debug-Fenster und Schluß
Ein Blick in die TIMPORT liefert dann das Ergebnis, daß noch nicht ein einziger Datensatz in die Tabelle geschrieben worden ist, der Fehler passiert also in dem Moment, wo Averp anfangen will, die Daten von Excel nach TIMPORT zu schaufeln und ich habe keine Ahnung woran es liegt.

Wir haben hier folgende Szenarien mit unterschiedlichem Ergebnis:
1. "Entwickler-Laptop" der Server und Client gleichzeitig ist und StandAlone arbeitet, ohne Verbindung zum Firmennetz. Hier funktioniert alles einwandfrei, egal ob als SYSDBA oder als Testuser mit unterschiedlicher Gruppenzuordnung, vorausgesetzt natürlich, die Zugriffsrechte der Gruppe stimmen
2. DAS NETZ mit der normalen Client/Server Architektur, wobei hier dann die Aufrufe des Utilities wie üblich von einem Client aus gestartet werden und hier funktioniert es eben nach dem oben beschriebenen Ablauf nicht.

Deshalb folgende Frage (und Idee)
Kann es sein, daß die UNIVERSALIMPORT ins Stolpern kommt, wenn sie auf einem Client aufgerufen wird, der NICHT zugleich Server ist? Das ist nämlich der einzige Unterschied, den ich hier bei uns im Vergleich beider Umgebungen gefunden habe.

Die Versionsstände der Programmdateien sind gleich und wie folgt:
AVERP = 2.0.0.8
AVERPStart = 2.0.0.1
AVERPDesign = 2.0.0.4
AVERPAdmin = 2.0.0.3
Firebird = 1.5.3, den genau Build kann ich gerade nicht prüfen
GDB = 2006.B2.02

Mit der dringenden Bitte um Hilfe, da wir ansonsten unseren Stücklistenimport nicht hinkriegen und uns die Zeit wegläuft
Michael

[SYN17]

Der universellen Datenimport wurde bzgl. der beschriebenen Fehler im Netz getestet. Der Import verlief Fehlerfrei.
Als Grundlage diente die aktuelle AvERP.EXE in der Version 2.0.0.25, wie sie auch im Downloadbereich zu finden ist.
Durchaus möglich, dass es in der verwendeten Version 2.0.0.8 zu einem anderen Verhalten gekommen ist.
Sollte der Fehler auch in der aktuellen Version im Netz auftauchen, so können Sie uns die Exceltabelle zusammen mit einem Bildschirmausdruck der verwendeten Konfiguration für den Excelimport zusenden. Wir werden es gern in dieser Konstellation testen.