Hallo zusammen,
mich interessieren Eure Tipps/Erfahrungen bei der Ablösung einer MS
ACCESS-Lösung in einer Fachabteilung (Controlling). Und zwar existiert
eine "historisch gewachsene" Datenbank mit Informationen über
Finanzbeteiligungen; Inhalte sind i.d.R. öffentlich zugänglich und in
dem Sinne "nur" gesammelt (z.B. Anschrift, Name Geschäftsführer, ggf.
Geschäftsführerhistorie, Anteilsquote und weitere Anteilseigner;
teilweise Umsatz / EBIT der letzten x Jahre). Der Output sind entweder
Übersichtslisten oder z.B. Exporte bzw. Direktzugriffe für Serienbriefe.
Die Lösung wurde vor >15 Jahren mal mit der damaligen ACCESS-Version
erstellt, ist mittlerweile durch viele Versionen und eben so viele Hände
bzgl. Betreuung gegangen und einfach nicht mehr zeitgemäß. Jetzt wird
eine Ersatzlösung gesucht; dabei ist zunächst sowohl eine anpassbare
fertige Lösung möglich wie auch die Selbsterstellung - und für beides
hätte ich gerne Tipps.
Das in der Fachabteilung vorhandene Know-How umfasst MS Office, insb.
Excel und VBA; sowie in Grundzügen Programmierung ("Pascal", z.T. Java)
sowie SQL. Das klingt nach wenig, das Interesse und auch die
Voraussetzungen sind aber da, sich auch in andere Techniken etc.
einzuarbeiten. Zumal die Anforderungen (Stand heute) nicht besonders
hoch sind:
- Das Datenbankschema ist vorhanden; der bisherige Umfang ließe sich
auch grundsätzlich mit Exceltabellen bewältigen
- In der Regel keine gleichzeitigen Zugriffe, überschaubarer
Personenkreis <-> keine "besonderen" Anforderungen an ein
Berechtigungskonzept
- Zugriff nur innerhalb des Unternehmensnetzwerks, und zwar vom
jeweiligen Arbeitsplatzrechner (Windows) aus - keine Cloud-Lösung, keine
App
- da nur Fachanwender und überschaubarer Funktionsumfang: Keine
aufwendige GUI
- keine Mehrsprachigkeit (aber Darstellung von Unicodezeichen wäre gut)
Vor ca. 20 Jahren(!) hatte ich mich mal mit JavaServerPages und
JavaServlets sowie EJB, Tomcat/Apache beschäftigt und kenne aus den
Zeiten noch OR-Mapping. Letztlich soll die entstehende Lösung aber vor
allem durch die Abteilung selbst wartbar und (in Grenzen)
weiterentwickelbar sein. Wenn es zudem bzgl. Lizenzmodell frei wäre und
kostenlos, wären das weitere Pluspunkte. Wichtig ist, dass sich
vielleicht relativ schnell erste Umsetzungserfolge zeigen - also z.B.
Aufruf einer Website mit ersten Abfragefunktionalitäten.
Würdet Ihr anhand dieser Infos überhaupt auf Weblösungen (HTML5/JS)
gehen? Oder lieber eine Desktopanwendung (Clients) und einen DB-Server
(MariaDB) empfehlen? Ich bin da mit meinem Wissen halt wirklich nicht
mehr aktuell... Mir helfen neben Stichworten auch kurze Begründungen
oder weiterführende Links.
Eine Bitte noch: Ich sehe auch, dass dieser Forenbeitrag bzw. die
geschilderten Probleme deutlich unter dem Anforderungsniveau anderer
Fachfragen liegen - mir ist aber kein besserer Platz für eine solche
Anfrage bekannt, da ich ja eben keinen Auftrag an Freelancer vergeben
möchte noch bzgl. "irgendwas" schon festgelegt bin - entsprechend hat
auch Googeln bisher nicht weitergeholfen. Vielen Dank Euch im Voraus!
V.M. schrieb:> Die Lösung wurde vor >15 Jahren mal mit der damaligen ACCESS-Version> erstellt, ist mittlerweile durch viele Versionen und eben so viele Hände> bzgl. Betreuung gegangen und einfach nicht mehr zeitgemäß.
Was ist daran nicht zeitgemäß? Es wird wohl praktisch immer so sein,
dass wenn man eine bestehende Lösung komplett neu aufbauen würde (clean
slate), man Dinge heute anders machen würde. Solange die bestehende
Lösung aber grundsätzlich funktioniert, macht man das normalerweise
nicht, wenn man nicht gerade zu viel Zeit oder Geld hat.
Also: Was soll die neue Lösung können, was die alte Lösung nicht kann?
V.M. schrieb:> Würdet Ihr anhand dieser Infos überhaupt auf Weblösungen (HTML5/JS)> gehen? Oder lieber eine Desktopanwendung (Clients) und einen DB-Server> (MariaDB) empfehlen?
Warum sollte man das alles tun, wenn man die Funktionalität gar nicht
braucht?
V.M. schrieb:> - Das Datenbankschema ist vorhanden; der bisherige Umfang ließe sich> auch grundsätzlich mit Exceltabellen bewältigen
Das wäre der Wechsel von einer Katastrophe zum SuperGAU.
V.M. schrieb:> Aufruf einer Website mit ersten Abfragefunktionalitäten.> Würdet Ihr anhand dieser Infos überhaupt auf Weblösungen (HTML5/JS)> gehen? Oder lieber eine Desktopanwendung (Clients) und einen DB-Server> (MariaDB) empfehlen?
Das ist die sinnvollste Lösung. Nimm das was dir besser liegt. Wenn es
etwas einfacher sein kann, wäre Sqlite auch noch eine Idee.
Heiner schrieb:> Was ist daran nicht zeitgemäß?
Wann war MS Access denn jemals zeitgemäß???
IT-Abteilung schrieb:> Wann war MS Access denn jemals zeitgemäß???
Immer? Man kann ja von unseren Freunden aus Redmond halten, was man
will, aber für eine kleine Datenbank im Einzelplatzbetrieb ohne
irgendwelche Anforderungen an die Skalierbarkeit, von Laien oder
zumindest Anwendern ohne großartige Vorkenntnisse verwendbar, bei Bedarf
über VBA erweiterbar, ...
Wo ist das Problem? Abgesehen von einer grundsätzlichen Abneigung
gegenüber MS? Access kann das hier beschriebene Problem unzweifelhaft
lösen und tut das aktuell sogar schon. Warum sollte man daran etwas
ändern?
IT-Abteilung schrieb:>> - Das Datenbankschema ist vorhanden; der bisherige Umfang ließe sich>> auch grundsätzlich mit Exceltabellen bewältigen>> Das wäre der Wechsel von einer Katastrophe zum SuperGAU.
Ich würde es eher so ausdrücken: Es wäre eine absolut sinnlose
Verschlechterung der Situation. Access war ja wenigstens als DB (mit
Frontend) gedacht, Excel aber niemals.
> V.M. schrieb:
[Webscheiß]
> Das ist die sinnvollste Lösung.
Bullshit. Ein Haufen mehr Komplexität für Null mehr Nutzen, statt dessen
höhere Antwortzeiten und weniger komfortable Bedienung (letzteres nur
vielleicht, hängt davon ab, wie gut oder schlecht die ursprüngliche
Access-Anwendung programmiert war).
> Wann war MS Access denn jemals zeitgemäß???
Immer, selbst heute noch. Kommt darauf an, was man damit macht. Ist
sicher nicht gut für global verteilte Datenbanken mit Millionen von
Nutzern auf der ganzen Welt und Datenbeständen im Exabyte-Bereich. Aber
für die vom TO beschriebene Anwendung reicht es ganz sicher völlig aus.
Genau das ist der Punkt: ich erkenne keinerlei Notwendigkeit für einen
Wechsel IRGENDWOHIN. Wozu? Was genau soll das bringen?
Vermutlich gibt es in der Fachabteilung aktuell mindestens
einen Doofen, der zu Hause seine Schnuersenkel nach Farbe
in einer Exceltabelle verwaltet und mit Datenbanken nichts
anzufangen weiss.
Sonst wuerde so ein Thema niemals hochkochen.
Sehr schoen in der Praxis zu sehen, was fuer "Workflows"
von sogenannten Informatikern zusammengezimmert werden.
In Anwendung "A" ausdrucken und in Anwendung "B" dann
wieder eintippen.
1. Was bedeutet für dich denn zeitgemäss genau?
2. Welche Features fehlen?
3. Wie komplex sind die Daten? Anzahl Felder,Tabellen?
4. Wie viel Erfassungsformulare gibt es?
5. Welche Auswertungen werden gemacht?
Du scheinst eine Web Lösung anzustreben, rutscht dann aber wieder
teilweise in die Desktop Richtung - hat das mit den Anforderungen zu tun
oder kennst du dich eben mit Web Sachen ein bisschen mehr aus?
cppbert3 schrieb:> Du scheinst eine Web Lösung anzustreben, rutscht dann aber wieder> teilweise in die Desktop Richtung
Ich habe eine Firmensoftware mehr als 2 Jahrzehnte lang entwickelt und
eingesetzt, bestehend aus Windows-Programmen, aber das würde ich Stand
heute nicht mehr tun - eine browserbasierte Lösung hat den Vorteil auf
fast jedem Client lauffähig zu sein, auch unter Linux oder auf einem
Tablet, man muss sich nicht mehr mit immer neuen Windows-Updates
herumschlagen. Ich glaube auch nicht, dass das mehr Arbeit ist als
Desktopprogramme, qualifiziert muss man so oder so sein um die Software
zu pflegen. Das Rollout einer neuen Version ist natürlich einfacher,
wenn sich nur auf dem Server was ändert. Zeitweise hatte ich auch einen
Terminalserver und Thin Clients im Einsatz, das ist ja auch eine
serverbasierte lösung, aber aus verschiedenen Gründen aus der Mode
gekommen.
Ich hatte DBase und Nachfolger verwendet, aber heute kommt eigentlich
nur noch SQL in Frage. MS Access war für eine Einkaufssoftware ebenfalls
im Einsatz, aber da mussten wir mit regelmässigen Abstürzen mit
Datenvernichtung leben, weil Access in der Praxis nicht
mehrbenutzerfähig ist. Es wurde immer nachts ein Backup erstellt, aber
wenn mal wieder kein Zugriff mehr möglich war war eben die Arbeit eines
Tages umsonst (nicht kostenlos!).
Georg
V.M. schrieb:> Know-How umfasst MS Office, insb.> Excel
Man kann auch Exel/Calc mit z.B. postgresql verbinden (frag die Leute
die das später benutzen müssen was wollen..)
V.M. schrieb:> Voraussetzungen sind aber da, sich auch in andere Techniken etc.> einzuarbeiten
Sieh Dir doch mal APEX an https://apex.oracle.com/en/ Ist eine RAD
Umgebung und wenn Oracle Express als DB verwendet wird kostenlos.
Nachteil : funktioniert nur mit Oracle DB
Gruß Uwe
Zusammenfassung:
15 Jahre lang haben Laien etwas gebastelt, das jetzt nicht mehr wartbar
und tragbar ist und den Anschluss an die Gegenwart verloren hat.
Nun sollen wieder Laien etwas neues bauen, irgendwie was modernes mit
"Web", wovon keiner der Laien so richtig Ahnung hat, und das soll dann
besser werden.
Finde den Fehler.
V.M. schrieb:> - da nur Fachanwender und überschaubarer Funktionsumfang: Keine> aufwendige GUI
Auch Fachanwender haben Anspruch auf eine intuitive Bedienung, Buttons,
Listboxen, Menüs usw. gehören heute einfach dazu. Wenn du deine Anwender
zu einer Bedienung per Kommandozeile mit kryptischen Parametern zwingst
senkst du nur die Produktivität massiv ab. Gefallen würde das nur
fanatischen Linuxanhängern.
Georg
Experte schrieb:> 15 Jahre lang haben Laien etwas gebastelt, das jetzt nicht mehr wartbar> und tragbar ist und den Anschluss an die Gegenwart verloren hat.
Ist das wirklich so? Genau das würde ich bezweifeln.
Es mag sein, dass in dem Affenstall niemand mehr hinreichende
Kompetenzen besitzt, um den gewachsenen Code zu begreifen. Wenn aber
dieser Code aber funktioniert, beweist das nur eins: der derzeitige
Personalbestand ist vollkommen überbezahlt.
Denn: Wenn ein Programm tut, was es soll, sollte jeder Programmierer in
der Lage sein, herauszubekommen, warum das so ist und wie genau das
geschieht.
Engagement in der Fachabteilung in Ehren, aber die haben ja bestimmt
andere Sachen zu tun, beispielsweise Controllingzeug wofür sie bezahlt
werden.
Wenn's eine ordentliche Lösung werden soll, dann würde ich es extern
vergeben. Falls es auch eine Murxlösung tut, so scheint es mir zu sein,
dann würde ich das bestehende Access etwas aufhübschen.
So eine webbasierte Loesung kann sich aber keiner so eben
aus dem Aermel schuetteln. Ich kenne eine, die setzt auf
dem MS SQL Server auf, und benutzt eine skalierbare Anzahl
von Application Servern die die Arbeit machen.
Fuer sowas braucht man eine erkleckliche Anzahl von
Codierschweinchen, die einem so etwas zusammenzimmern.
Und, so etwas wie eigentlich auch nie fertig, weil sich
auch die Anforderungen an die Applikation aendern.
Diese Software wird von ca. 500 Clients aus parallel genutzt.
Da kann man sich auch die geforderte Leistungsfaehigkeit
in etwa zusammenreimen...
Die Antwortzeiten liegen im Bereich von 200 ms bis 1000 ms
mit einem Maximum bei 300 ms.
Sucht euch einen oder mehrere Freilandser und lasst den/die
euren Kram in kleinen Schritten auf einen Neuentwurf portieren.
Und der sollte wohl zweckmaessigerweise wieder Access verwenden.
Und schnell wird das auch nichts. Also eher > 3 Monate.
Das aber auch nur, wenn ein konsistentes und nicht staendigen
Aenderungen unterworfenes Pflichten/Lastenheft existiert.
Viel Erfolg!
1.Von einer funktionierenden DB zurück zu Excel kann nur ein Amateur
raten. 2.Man sollte eher mal genauer nachdenken, was man wirklich
braucht. Falls ein außenstehender Programmierer ans Werk gehen soll,
müßte er recht genau wissen, wie die Abläufe in der Firma sind! Sonst
baut er ein optisch schönes Tool was keiner gebrauchen kann!
Heiner schrieb:> IT-Abteilung schrieb:>> Wann war MS Access denn jemals zeitgemäß???>> Immer? Man kann ja von unseren Freunden aus Redmond halten, was man> will, aber für eine kleine Datenbank im Einzelplatzbetrieb
Mööt! Wenn ich den TO richtig verstanden habe, geht es gerade nicht um
einen Einzelplatzbetrieb.
V.M. schrieb:> Die Lösung wurde vor >15 Jahren mal mit der damaligen ACCESS-Version> erstellt, ist mittlerweile durch viele Versionen und eben so viele Hände> bzgl. Betreuung gegangen und einfach nicht mehr zeitgemäß. Jetzt wird> eine Ersatzlösung gesucht; dabei ist zunächst sowohl eine anpassbare> fertige Lösung möglich wie auch die Selbsterstellung - und für beides> hätte ich gerne Tipps.
Nun, Du schreibst zwar, daß keine parallelen Zugriffe notwendig seien,
aber wenn ich das richtig verstehe, wird die Software doch von mehreren
Menschen genutzt. Deswegen würde ich in solchen Fällen immer von der
Verwendung einer dateibasierten Datenbank abraten und zu einer
zentralisierten Lösung raten. Abgesehen davon, daß diese auch von
mehreren Usern gleichzeitig genutzt werden kann -- was womöglich
spätestens bei einem Wachstum der Abteilung und / oder der Umverteilung
von Aufgaben notwendig werden kann -- bietet eine zentralisierte Lösung
auch noch erhebliche Vorteile bei Themen wie dem Backup, der Wartung und
der Pflege.
Außerdem bietet eine zentralisierte Lösung in Deinem Fall noch einen
weiteren großen Vorteil, nämlich den einer schrittweisen Migration. Aus
eigener Erfahrung weiß ich, daß in selbstentwickelten Office-Lösungen
häufig jeder Kollege seins macht und sich die Dinge, die er braucht,
selbst einbaut. Diese ganzen verschiedenen Lösungen und Lösungswegen
einzusammeln und in einer zentralisierten Software zu implementieren,
ist nach meinen Erfahrungen eine ziemlich aufwändige Angelegenheit und
führt gerne auch mal zu Konflikten. Konflikte unter den Kollegen sind
aber das letzte, was man haben möchte, denn einerseits erschweren sie
die Einführung neuer Software bis hin zu Kollegen, die die Mit- und
Zusammenarbeit verweigern, andererseits bleiben diese Konflikte am Ende
immer an dem hängen, der die neue Lösung entwickelt.
Ich ganz persönlich würde daher ein schrittweises Vorgehen vorschlagen:
im ersten Schritt wird ein zentrales SQL-RDBMS installiert und in
Betrieb genommen, also zum Beispiel auch das Backup und idealerweise
zudem ein Monitoring eingerichtet. Dann werden die Bestandsdaten und
-Schemata auf dieses zentrale RDBMS migriert und den Kollegen ein
Zugriff über ODBC ermöglicht; so können die Kollegen weiterhin mit der
gewohnten Software (hier: MS-Office) arbeiten, aber eben auf einer
zentralen DB.
Danach kann man immer noch entscheiden, ob man eine ebenfalls
zentralisierte Web-Anwendung bauen möchte. Da die Kollegen aber
weiterhin arbeitsfähig sind, kann man sich sowohl mit der Entscheidung,
als auch -- bei positiver Entscheidung -- einer Implementierung Zeit
lassen und die Kollegen an einer eventuellen Implementierung aktiv
beteiligen. Das erhöht die Akzeptanz der Anwender, sie werden sich
dadurch ernst genommen fühlen und wesentlich engagierter einbringen.
Der grundsätzliche Nachteil einer webbasierten Software ist, daß sie
sich nicht so leicht in einen existierenden Workflow auf Basis von
MS-Office integrieren läßt. Man kann aber mal einen Prototypen bauen,
ihn den Kollegen vorstellen, und sie dann an einer Entscheidung
beteiligen. Ja, man kann MS-Dateiformate zum Beispiel auch mit Python
erzeugen, oder den Datentransfer von Web zu Office zum Beispiel über
CSV-Dateien machen, aber ob und wie gut das funktioniert, hängt von den
konkreten Anwendungsfällen ab.
Was die zur Entwicklung einer webbasierten Software genutzten
Technologien angeht, würde ich aktuell von Java abraten -- einerseits
wegen der immer noch ungeklärten Lizenzsituation, andererseits sind
Entwicklung und Betrieb von Webapplikationen in Java vergleichsweise
aufwändig und möglicherweise nicht zukunftssicher. Heute gibt es
beispielsweise keinen freien Web Application Server, der die aktuellen
Standards unterstützt, und die kommerziellen Web Application Server wie
IBM Websphere oder Redhat JBoss kosten einerseits Geld und neigen
andererseits leider auch dazu, die aktuellen Standards... sagen wir,
etwas unterschiedlich zu interpretieren. Freie Web Application Server
wie Wildfly hingegen (auf dem JBoss basiert) neigen leider oft zu
Instabilitäten durch Memory Leaks und Race Conditions, oder
unterstützten die heute aktuellen Standards (noch) nicht vollständig,
wie der beliebte Apache Tomcat.
Meine ganz persönliche Empfehlung wäre daher, die Programmiersprache
Python und das Micro-Webframework Flask zu verwenden. Die Entwicklung in
einer nicht-typsicheren Sprache, die einen großen Teil der
meistverwendeten Bibliotheken bereits an Bord hat, spart massiv
Entwicklungszeit. Durch Bibliotheken wie Pandas zur Analyse und Bokeh
zur Visualisierung, Weazyprint zur Erzeugung von PDFs und weitere
Libraries läßt sich nahezu beliebiger Funktionsumfang integrieren, ohne
ihn selbst entwickeln zu müssen, was wiederum Zeit spart. Und im
Zweifelsfalle kann man mit Flask-Admin sogar automatisch Anzeigen und
CRUD-Formulare aus seinem Datenbankmodell erzeugen, sofern man dieses
mit dem OR-Mapper SQLAlchemy erzeugt hat... Gleichzeitig ist Python
jedoch so einfach, daß interessierte Kollegen gleich bei der
Einarbeitung und der Implementierung mitarbeiten können (Tipp: von
vorneherein mit einem zentral installierten Versionskontrollsystem wie
Git arbeiten!).
Als SQL-RDBMS würde ich persönlich übrigens PostgreSQL empfehlen. Das
ist stabil, performant und flexibel, bietet von allen mir bekannten
RDBMS die umfangreichste Funktionalität (bis hin zur Möglichkeit eigener
Erweiterungen und Datentypen), im Zweifelsfall ist es sogar möglich,
Stored Procedures in Python zu schreiben...
HTH, YMMV. ;-)
V.M. schrieb:> vor >15 Jahren mal
Das übliche Problem. Vor Jahren mit einem kleinen irgendwas.xls
angefangen und weil es "so schön ging", arbeitet jetzt die ganze Firma
damit? Den Wildwuchs wieder einzufangen und in eine akzeptable DB-Lösung
zu überführen macht Aufwand. Je exotischer die Lösung wird, desto
abhängiger wird man von einzelnen SW-Entwicklern. Mit "mal schnell" wird
wohl nix. Schau Dir erst mal ein paar ähnliche Referenzlösungen Deiner
Entwickler an.
Vielen Dank für die zahlreichen Statements - das hilft mir sehr;
gleichzeitig muss ich das für mich jetzt ein wenig sortieren. Wer noch
weitere Ideen dazu hat, gerne her damit!
Idealerweise hat jemand eine sehr ähnliche Situation gehabt und das dann
gelöst und mag sich mal detailliert austauschen - welche Lösungsansätze
haben im Nachhinein gut funktioniert, und welche waren dann doch
Sackgassen?
V.M. schrieb:> Vielen Dank für die zahlreichen Statements - das hilft mir sehr;> gleichzeitig muss ich das für mich jetzt ein wenig sortieren. Wer noch> weitere Ideen dazu hat, gerne her damit!
bisschen schwierig wenn du keine Fragen beantwortest - also nochmal
und bitte so genau wie möglich
1. Was bedeutet für dich denn zeitgemäss genau?
2. Welche Features fehlen?
3. Wie komplex sind die Daten? (Anzahl Felder,Tabellen)
4. Wie viel Erfassungsformulare gibt es?
5. Welche Auswertungen werden gemacht?
6. Wie viele Nutzer - nicht zeitgleich - gibt es?
> Idealerweise hat jemand eine sehr ähnliche Situation gehabt und das dann> gelöst und mag sich mal detailliert austauschen - welche Lösungsansätze> haben im Nachhinein gut funktioniert, und welche waren dann doch> Sackgassen?
Wenn es wenige Tabellen sind und nur ein paar Eingabefehler, wenig
Datenverbindungen, kleine Hierarchien und man Ahnung hat kann das wenige
Stunden dauern - egal mit welcher Technologie - wenn man keine Ahnung
hat (oder jemand ahnungslosen findet der es macht) ist es schwer
abzuschätzen wie lange ihr braucht
cppbert schrieb:> und welche waren dann doch>> Sackgassen?
Glaubst du jemand erzählt hier voller Stolz wie er gescheitert ist?
Ausserdem ist das nicht so einfach zu definieren, in der Praxis
funktioniert selbst das ungeeignetste Konzept, von unfähigen
Programmierern realisiert und völlig undokumentiert immer noch gut
genug, dass es 20 Jahre lang eingesetzt wird.
Es ist dabei erstaunlich mit welcher Fantasie und Improvisationsgabe die
Leute auch mit totalem Schrott noch zurechtkommen. Man gewöhnt sich halt
dran.
Georg
Schau dir mal Claris Filemaker Pro an.
Die Demo ist 14 Tage ohne Einschränkungen lauffähig. Läuft auf Windows,
MacOSX und iOS-Geräten. Die Linux-Version ist im Beta-Stadium.
Filemaker-Lösungen kann man lokal oder im Netzwerk betreiben. Der
Netzwerkzugriff ist per Client (lokale FM-Installation) und per
Webbrowser möglich. Die "Player"-Software für Mobilgeräte
("Filemaker-Go") ist kostenlos ... Eine Nutzung unter Anrdoid ist mit
Fremdsoftware möglich: https://filemaker.livecode.com/
Typische Arbeitsweise: Die Software wird in der IDE einer lokalen
Installation entwickelt (egal ob Mac oder Win) und dann auf den
FM-Server hochgeladen. Aber auch dort kann man jederzeit (entsprechede
Rechte vorausgesetzt) an GUI und DB-Struktur arbeiten. Anstatt VBA gibt
es eine eigene Skriptsprache, deren Funktionsumfang durch eigene
Funktionen oder Plugins erweitert werden kann.
An einen Filemaker-Server kann man mit externen Programmen per ODBC/SQL
"andocken", Filemaker kann z.B. Excel-Tabellen und CSV im- und
exportieren ... u.v.a.
