Menu

Zusammenhang con / ini / wfd

2015-03-18
2015-03-23
  • Matthias Fuchs

    Matthias Fuchs - 2015-03-18

    Hallo zusammen,

    ich habe noch ein kleines Verständnisproblem.

    Bisher hatte ich nur ein Archiv. Diesem lagen folgende Dateien zu Grunde

    ada1-mjf.com
    ada1-mjf.wfd
    scripts.ini

    Die scripts.ini beginnt wie folgt:

    [Scripts]
    Profil=ada1-mjf
    unverteilt=unverteilt
    Typ=CRE
    archquelle=true
    ...

    und genau hier liegt mein Problem.

    Ich habe nun eine neue Datenbank angelegt für einen vollkommen neuen Bereich:

    Erzeugt wurde dabei automatisch:

    bitfarm_sbc.con

    bitfarm_sbc.wfd (wurde nicht erzeugt: Muss ich diese selbst anlegen ? Ich neheme es an...)

    Doch was ist nun mit der "scripts.ini" ?

    Denn hier steht ja ein Profil drin und auch ein Archiv-Template ("unverteilt") fürs scannen.

    Und wie bzw. wo konfiguriere ich welche .wfd-Datei benutzt wird ? Gilt hier .con-Name gleich .wfd-Name ?

    Besten Dank vorab für die Hilfe.

    Gruß mjfuchs

     
  • bitfarm17

    bitfarm17 - 2015-03-18

    Guten Tag Herr Fuchs,
    das haben Sie soweit richtig erkannt. Die neue wfd Datei muss händisch angelegt werden und den gleichen namen tragen wie die con datei. Unsere Scripte erkennen automatisch welche wfd datei zu verwenden ist. Natürlich müssen sie dann in der scripts.ini dann auch den eintrag Profil= und unverteilt= anpassen. Der Schalter unverteilt= gibt dabei an, in welches Archiv Dokumente einlaufen, die beim Archivieren nicht manuell oder automatisiert in ein spezielles Zielarchiv sortiert wurden. Weiterhin sollten Sie auch beachten, das immer nur ein Profil gleichzeitig verwendet werden kann.

     
  • Matthias Fuchs

    Matthias Fuchs - 2015-03-18

    Hallo bitfarm17,
    danke für die Antwort. Ich verstehe eine Sache offensichtlich noch nicht. Die Funktion der "scripts.ini".

    Ich habe auf meinem (einzigen) Rechner ein Archiv für meine "Private" Tätigkeit und ein weiteres (eigene Datenbank) für mein kleines in der Gründung befindliches Unternehmen.

    Diese haben ja nichts miteinander zu tun.

    Ich muss für die beiden Datenbanken mich beim Viewer ummelden und natürlich auch das selbe bei ManuScan.

    Doch wie spielt nun die scripts.ini da rein, wenn ich zwei Datenbanken verwende ? Was bedeutet es insgesamt für mich, wenn ich nur eine scripts.ini und damit nur ein Profil verwenden kann.

    Wie sieht die Lösung aus ?

    Besten Dank vorab.

    Gruß

    mjfuchs

     
  • bitfarm17

    bitfarm17 - 2015-03-18

    Guten Tag Herr Fuchs,
    die Funktion der scripts.ini besteht darin, Parameter die von den scripten des Systems benötigt werden (z.B. archivierung.vbs, autoscan.vbs etc.) zur Verfügung zu stellen.

    Somit greifen die verarbeitenden scripte auch nur auf die con Datei zu, welche in der scripts.ini unter Profil= angegeben ist.

    Die Ausführbaren Dateien wie ViewerV3 und Manuscan holen sich die Verbindungsdaten zur Datenbank direkt aus der con Datei des gewählten Profils.

    Bestünde vielleicht die Möglichkeit nur eine Datenbank zu verwenden und die Dokumente dafür mit Hilfe entsprechender Strukturen des Archivbaumes zu pflegen?

     
  • Matthias Fuchs

    Matthias Fuchs - 2015-03-18

    Hallo bitfarm17,

    genau das wollte ich ja vermeiden. Insbesondere sollte die geschäftliche Datenbank irgendwann ja auf eigene Systeme migriert werden, sobald das Unternehmen auch genügend erwirtschaftet. Und bei verschiedenen DB erschien mir eine spätere Migration/Trennung leichter, zumal eine private und geschäftliche Archivstruktur sich doch sehr unterscheiden.

    Meine private (familiäre) Archivstruktur ist sehr an meinem Ablagesystem orientiert (ein nicht ganz korrekter, aber für mich optimaler Ansatz), während meine geschäftliche Struktur den marktüblichen entspricht. Ich betreue selbst ein Archiv bei einem großen Schweizer Versicherer.

    Außerdem ist die private .wfd schon recht umfangreich und hat rein garnichts, mit der zu tun, die ich für mein Unternehmen benötige. Hier würde ich Daten (aus der .wfd) mischen, die später niemand interessieren, weil sie nicht zusammen gehören.

    Außerdem erschließt sich für mich die Möglichkeit der Nutzung verschiedener Datenbanken, .con-Profile und .wfd-Dateien nicht, wenn die Wahjl des Profils bei der Anmeldung (Viewer/Manuscan) nicht dazu führt, dass auch die entsprechende scripts.ini benutzt oder diese nach Profilen unterteilt werden kann. Ich kann ja Bitfarm auch nicht zweimal auf meinem Rechner installieren. Macht ja echt keinen Sinn.

    Unternehmen benutzen ja auch Trennungen z.B. Mandanten. Und wenn es da unterschiedliche Strukturen gibt würde diese Trennung auch benötigt.

    Ich hoffe für mein Problem gibt es doch noch eine Lösung.

    PS: Wenn Sie es brauchen habe ich hier noch eine UDL-Datei für Notepad+++, ich denke da würden sich manche User drüber freuen...

    Gruß Matthias Fuchs

     
  • bitfarm4

    bitfarm4 - 2015-03-23

    Hallo Herr Fuchs,

    womit Sie sich am Client anmelden, hat natürlich keinen Einfluss darauf, mit welchen Einstellungen die Archivierung von Dokumenten läuft, denn Viewer oder Manuscan verwenden die scripts.ini ihrerseits nicht.
    Natürlich können Sie am Client zwischen beiden Profilen wechseln. Wenn Dokumente mit Manuscan archiviert werden, wird das Profil, das die Skripte zu verwenden haben, über die von Manuscan erzeugte Job-Datei mitgegeben.
    Wenn Sie außerdem in beiden Archiven keine gleichnamigen Einzelarchive haben (oder mit Template- und Importordnernamen tricksen), können Sie die Archivierung mit Autoscan, speziellen Archivdruckern und über den Importordner mittels der Templates - welche wiederum die Vorlage für die Job-Datei sind - in die verschiedenen Mandantenarchive steuern.
    Eigentlich hat dann nur noch der Eintrag für "unverteilt" in der scripts.ini eine Bedeutung, wenn Sie über die oberste Ebene des Import-Ordners archivieren.

    Da man schon aufpassen muss, in dieser Konstellation nicht die Übersicht zu verlieren, empfehlen wir, wenn es sich vermeiden lässt, eher zwei Archive in einer Datenbank, deren Sichtbarkeit für unterschiedliche Nutzer - mitunter von verschiedenen Unternehmensteilen - sich ja ohne Weiteres über die Berechtigungen steuern lässt.

    Gruß,

    bitfarm4

     

Log in to post a comment.