Access: Tabellen zusammenfassen, Abfragen erstellen

[ch0815]

Ich habe mir hier ein Access/VBA-Projekt ans Bein gebunden, obwohl ich es nicht kann, aber Kollegen auch nicht und ich habe eh sonst nichts zu tun und skripte ab und zu ein bisschen was, daher hab ich gesagt ich schau es mir mal an.
Natürlich lasse ich mir von der KI helfen, wollte aber trotzdem auch mal echte Menschen mit Erfahrung fragen nach einem grundlegenden Konzept der Sache. Vielleicht gibt es ja hier jemanden der etwas dazu sagen kann.

Also bei einem Kunden werden Sharepoint Tabellen etwa monatlich nach Access exportiert/archiviert. Jeweils in eine neue access-Datei. Also nur eine Tabelle pro Datei.
Es gibt 3 verschiedene Tabellentypen, ich nenne sie jetzt mal Projekte, Angebote, Bestellungen (heißen original anders, aber aus "Geheimhaltungsgründen" kann/darf/will ich nicht die Originalbezeichnungen nennen).
Einige Spalten dieser Tabellen sind gleich, sagen wir mal bspw. Kunde, Lieferant, Mitarbeiter (wieviele genau weiss ich auch noch nicht).

Man möchte nun über das ganze Archiv suchen, was so ja nicht geht, da es aus lauter Einzeldateien besteht.
Wenn man nach bspw. Mitarbeiter sucht, möchte man alles finden wo der MA beteiligt ist, also Suche in Projekte und Angebote bspw., dann noch nach Zeitraum gefiltert etc.
(aktuell ca. 200 einzelne access Dateien).
Mein Grundgedanke war nun, alle Tabellen in eine access Datei zu importieren. Die Tabellen enthalten binäre Anhänge (E-Mails). Diese exportiere ich in Dateien, da höchstwahrscheinlich alles ziemlich langsam wird, denn insgesamt sind das aktuell so ca. 40 GB.
Das exportieren und verlinken habe ich schon getestet, das funktioniert soweit.

Momentan ging ich noch von aus dass ich beim Import jede Tabelle original lasse und nur entsprechend mit Exportdatum benenne. Dann hätte man sehr viele Tabellen a la Projekte_2025_1, Projekte_2025_2, Angebote_2025_1, Angebote_2025_2, ...
Ist aber wahrscheinlich nicht so sinnvoll und sollten alle gleichartigen Tabellen in eine Tabelle überführt werden, so dass man nur noch 3 Tabellen hat Projekte, Angebote, Bestellungen. -> das ist wohl sinnvoller?
Ich muss allerdings nun jede einzelne Tabelle prüfen, denn das Format scheint tlw. auch noch unterschiedlich zu sein. Also nicht alle "Angebote" haben die gleichen Felder etc. Da lasse ich mir gerade ein Skript erstellen, das die Tabellenentwürfe exportiert damit man sie vergleichen kann.

Letztlich hätte man dann ein access-file "Archiv" mit den Tabellen Projekte, Angebote, Bestellungen, (+ Attachments, in dem die ins Filesystem exportierten Anhänge verwaltet werden). alles zusammmengefasst dürfte dann jede Tabelle einige 10.000 Zeilen haben, da die binären Anhänge exportiert sind sollte das aber kein Problem sein?

Nun wäre das das Backend.

Die Abfragen sollte man dann in einer getrennten Frontend Access machen habe ich gelesen. Wie das genau geht muss ich mir noch beibringen lassen von der KI.

Die Abfragen/Suche sind nun das wo ich noch gar keinen Plan hat. Der Kunde auch nicht...
Hat man nur eine Tabelle, so könnte man in einzelnen Spalten suchen/filtern und Ergebnis noch sortieren. Bei mehreren Tabellen geht das aber so nicht.
Außerdem ist die Standardtabelle in Access nicht gerade super nutzerfreundlich. Gibt es hier "schönere" Tabellen? Ich geb mal als Beispiel das web-Framework von dem ich ein wenig Ahnung habe, ag-grid: https://www.ag-grid.com/example/

Über mehrere Tabellen stelle ich mir zum Einstieg ein Formular vor mit Such/Filterfeldern, und als Ergebnis erhält man dann eine bis drei Tabellen, die man dann noch mit den Filter/Sortiermöglichkeiten der Tabelle weiter verfeinern kann.

Theoretisch bräuchte man für jedes Feld das "unique" in den Tabellen ist, ein Suchfeld im Formulat, plus ein globales Suchfeld. Jeweils mit wildcards etc.
Bspw suche ich dann nach Mitarbeiter XY, und erhalte als Ergebnis dann z.B. die Tabellen Projekte und Angebote, an denen der MA beteiligt war (in Bestellungen kommt er nicht vor als Beispiel). Die kann ich dann weiter runterfiltern.
oder ich suche Freitext, ich weiss da war irgendwas mit "haus" also globales Suchfeld "haus" und erhalte alle Tabellen die in irgendeinem Feld etwas mit haus enthalten. Das wäre in ag-grid z.b. der quickfilter, in der Demo das Filterfeld rechts oben.

Eingaben in ein Formular lassen sich dann sicherlich in entsprechende SQL-Abfragen übersetzen und die Ergebnisse als Tabellen darstellen.
Nun möchte ich aber bei der Suche übers Formular auch eine "Autofilter"-Liste haben, ag-grid nennt das quick-filter: https://www.ag-grid.com/javascript-data-grid/filter-set/
Also ich muss nicht vorher wissen was ich suche sondern kriege eine Liste was ich suchen kann. Hier dann über alle drei Tabellen. Wenn Kunden A, B und C nur in Projekten stehen, aber Kunde D in Projekten und Angebote, so soll im Suchfeld Kunden per dropdown oder ähnliche Auswahl A, B, C und D ausgewählt werden können. (oder halt Freitext)

So, jetzt schon sehr viel Text und wahrscheinlich kann mir keiner mehr folgen...?
Ich werde es wohl mal graphisch darstellen müssen, falls es hier überhaupt jemanden gibt, der mir Hinweise geben kann/will.

Danke schon mal...

 

[chr1zZo]

Dein Konzept ist grundsätzlich richtig. Ein paar Anmerkungen und Korrekturen aus der Praxis:


Backend-Konsolidierung: ja, aber Access als Speicher ist das Risiko


Drei Zieltabellen (Projekte, Angebote, Bestellungen) statt 200 datierter Einzeltabellen ist absolut richtig. Aber: Access-Datenbanken haben ein hartes Limit von 2 GB pro .accdb-Datei. Auch wenn du die E-Mail-Anhänge ins Filesystem auslagerst (richtig gedacht), können einige zehntausend Zeilen mit Textfeldern, Memo-Feldern und Indizes je nach Inhalt durchaus an die Grenze kommen – vor allem wenn das Archiv weiter wächst.


Ernsthafte Empfehlung: Nimm als Backend SQLite oder PostgreSQL statt Access-Backend, und benutze Access nur als Frontend (verlinkte Tabellen via ODBC). SQLite ist eine einzelne Datei, kein Server nötig, kein 2-GB-Limit, deutlich schnellere Volltextsuche (FTS5!), und du kannst es mit deinem Python-Hintergrund viel besser pflegen als VBA-Importroutinen. Access-Frontend + SQLite/Postgres-Backend ist ein etabliertes Muster.


Das Heterogenitäts-Problem ist der eigentliche Knackpunkt


Dass nicht alle „Angebote" dieselben Felder haben, ist der Teil, der dir die meiste Arbeit macht – nicht das Suchen. Dein Skript zum Export der Tabellenentwürfe ist genau richtig. Plane für jede der drei Zielentitäten:

• Ein Kernschema mit den gemeinsamen Spalten (Kunde, Lieferant, Mitarbeiter, Datum, Quelldatei, Exportdatum).
• Pro Zeile zusätzlich eine Spalte Quelldatei und Quelldatum (für „Zeitraum"-Filter und Nachvollziehbarkeit).
• Für die abweichenden/seltenen Felder entweder zusätzliche Spalten oder ein JSON-/Memo-Feld („extra_fields"), in das du den Rest kippst. So gehen keine Daten verloren, auch wenn das Schema über die Jahre driftet.

Mach den Import idempotent und protokolliere, welche Quelldatei welche Felder hatte – sonst findest du Mapping-Fehler nie wieder.


Frontend/Suche: Access-Bordmittel können das meiste


Dein gedankliches Modell (Suchformular → übersetzt in SQL → Ergebnistabellen, dann weiterfiltern) ist genau das, was Access mit ungebundenen Formularen macht. Konkret:

• Ein ungebundenes Suchformular mit Feldern für Mitarbeiter, Kunde, Lieferant, Zeitraum-von/bis und einem globalen Freitextfeld.
• Beim Klick baust du dynamisch eine SQL-WHERE-Klausel und setzt sie als RecordSource des Ergebnis-Unterformulars (Datenblattansicht). Wildcards mit Like "" & [Feld] & "".
• Globale Freitextsuche = ein OR über alle relevanten Textspalten. Hier zahlt sich SQLite FTS5 massiv aus, weil ein OR LIKE '%...%' über zehntausende Zeilen mal drei Tabellen in reinem Access spürbar lahm wird.

Drei Tabellen gleichzeitig durchsuchen: entweder drei separate Unterformulare (eins pro Entität, jedes mit eigener gefilterter RecordSource), oder eine UNION-Abfrage über die gemeinsamen Spalten, wenn dir für die Trefferübersicht Kunde/Lieferant/MA/Datum/Typ reichen – und der Klick auf einen Treffer öffnet dann den Volldatensatz der jeweiligen Tabelle.


Dein ag-Grid-Wunsch (Set-Filter / Quick-Filter)


Das ist der Punkt, wo Access-Datenblätter schwächer sind als ag-Grid, aber nicht hilflos:

• Die Autofilter-Dropdowns (deine A/B/C/D-Auswahl) löst du mit Combobox-RowSources, die eine SELECT DISTINCT Kunde FROM (...) über alle drei Tabellen ziehen. Das ist exakt das Set-Filter-Verhalten – die Liste kommt aus den Daten, nicht aus Vorwissen.
• Datenblattansicht in Access hat eingebaut Spaltensortierung und Spaltenfilter (Rechtsklick), das deckt das „weiter runterfiltern" nach der ersten Suche ab.
• Ein echtes ag-Grid-Erlebnis bekommst du in Access nicht. Wenn dir die Grid-Ergonomie wirklich wichtig ist, ist die ehrliche Alternative ein schlankes Web-Frontend (FastAPI + SQLite + ag-Grid) – was genau in deiner Komfortzone liegt. Access-Frontend ist der Weg, wenn der Kunde zwingend „eine Access-Datei" will; Web-Frontend ist technisch der angenehmere Weg für dich und liefert die Grid-Features gratis.

Vorschlag für die Reihenfolge


Erst Schema-Inventur abschließen (welche Felder gibt es real, pro Entität), dann Zielschema festlegen, dann Import-/Konsolidierungspipeline (idempotent, mit Quell-Logging), dann erst Frontend. Die Suche ist am Ende der einfachste Teil – das Schema-Mapping ist die Arbeit.


Eine Frage, die deine Architektur stark beeinflusst: Soll das Ganze read-only sein (reines Archiv-Durchsuchen), oder will der Kunde in den Daten auch editieren/ergänzen? Bei read-only wird vieles einfacher, und das Web-Frontend wird klar attraktiver.

 

[ch0815]

Vielen Dank, aber das hast du jetzt natürlich auch der KI vorgeworfen...?

Ich müsste eigentlich schon bei Access bleiben, der Kunde soll das dann ja zukünftig selber bedienen/erweitern. Außerdem hab ich auf dem Kundensystem keine Adminrechte etc. SQLite dürfte vermutlich gehen, aber da kennt sich dann der Kunde erst recht nicht mit aus. Ebenso Python.

Ich denke nicht, dass der binärbefreite reine Textcontent in den nächsten Jahrzehnten die 2 GB erreichen wird. Wobei ich da rudimentär die Daten mal sichten und dann rechnen muss. kommt natürlich noch drauf an wie Access das "bisschen Text" was noch übrig bleibt dann aufbläht.

PS: Ich gehe eigentlich von read only aus, müsste da aber nachfragen. Alles andere würde aus meiner Sicht aber keinen Sinn ergeben. Ich finds jetzt schon bedenklich, dass die aktuellen access-files alle von jedem geändert werden können...

 

[chr1zZo]

Claude 4 the Win

Wieso nicht einfach ein Frontend darauf aufbauen? Der Kunde muss doch die Datenbank weder angreifen noch das Python starten, das kannst du Automatisieren. Access ist ja sowas von Oldsql bei dem was der Kunde macht. Du kannst die Daten auch abgreifen ohne Admin. Aber mit rechten wäre schon nice.

Wie willst du dem Kunden etwas anpassen ohne Rechte? Klar, vorher sauber Backupen bevor man sowas macht.

 

[ch0815]

ich hab da ja keinen server etc. wo soll denn python laufen? ich hab es nur lokal auf meiner Kunden-VM installiert, um Dinge für quasi mein eigenes Projekt hier zu machen.
Das Access-Zeug ist für eine andere Abteilung, da hab ich sonst nichts mit zu tun.
Den monatlichen sharepoint-Export und hinzufügen zur DB müssen die dann selber können.

Zumal wir hier wahrscheinlich sowieso alle bald keinen job mehr haben...

 

[chr1zZo]

Python kann doch Lokal laufen. Aber wenn du eh keine Rechte hast, wie willst du dann überhaupt irgendwas sinnvolles machen? Sich etwas ans Bein zu binden mit "mal schauen wie ich das hinbekomme" ist ja auch nicht die Lösung, auch wenn du das nicht wolltest. Normalerweise erstellt man erstmal eine Analyse (Ist-Zustand, Struktur, was wird benötigt, was ist das Ziel).

Rate mal warum so viele an Access verzweifeln Hat mal irgendwer eingeführt, funktioniert irgendwie, der Zuständige ist aber schon lange in Rente Unnötige Daten und Produktpflege, mit Abhängigkeit von MS Office ^^ Würde ich schön auslagern mit Datenbank und Frontend/ERP/CRM.

Wenn es ein Kunde ist, würde ich ihm eine moderne Lösung vorschlagen und damit "Weg von Access".

ERP mit Odoo Open Source delpoyen, eigenes Frontend drauf oder im eigenen von Odoo arbeiten, Daten Import von Access, Logiken verknüpfen, Rollensystem, Log (Wer hat wann was gemacht) usw.

 

[ch0815]

Ja die Analyse mache ich gerade, zusammen mit etwas rumprobieren/recherchieren was so möglich ist. Ich will halt jetzt nicht sagen "geht nicht". Irgendwas sinnvolleres als den Jetzt-Zustand wird man schon hinbekommen was dann für den Kunden nützlicher ist.
Dia Access-Dateien haben Lese und Schreibrechte für jeden. Also in dem Rahmen kann ich da schon was machen. Natürlich könnten andere auch python lokal installieren etc. aber das will ich niemandem da "zumuten". für ein webfrontend bräuchte ich nen webserver, den kriege ich da nicht. will ich auch gar nicht. wer administriert den dann etc.?
klar, mit python kann ich lokal nen webserver simpel starten. lokal. bräuchte dann also dort jeder MA lokal Python installiert und per Skript dann webserver lokal starten lassen.. viel zu komplex für unbedarfte. zumal ag-grid in der gewünschten version kostenpflichtig wäre.

Achja, ich krieg da zwar Python3, aber keine zusätzlichen Module, nur was die Installation so mit sich bringt...

Außerdem ists dann doch am einfachsten Frontend/UI in Access zusammenzuklicken.

 

[chr1zZo]

Nur weil beim Kunden kein Server steht ist das doch keine Verzweiflung. Klar, ein kleiner PC der als "Intranet" aggiert wäre ein Vorschlag, ansonsten tut es ein kleiner VPS. Ein Webserver der Art brauch nicht all zu viel Pflege wenn einmal korrekt aufgesetzt. Na ihr scheint ja eine Firma zu sein die Aufgaben für Kunden erledigen oder? Dann muss man mal in die Angebots/Verkaufsphase gehen. Der Kunde ist auch nur "Unwissend" und möchte ein Lösung. Wenn sie gut ist, bezahlen die meisten fast alles

 

[ch0815]

Der Kunde ist eine Firma mit mehreren 10.000 MA... dementsprechend schaut da die IT-Landschaft aus. Man bekommt da nix ohne superkomplizierten Antrag, Begründungen, Freigaben durch div. Gremien etc., Man kann auch nix selbst installieren außer was per Intranet zur Selbstinstallation freigegeben ist. Python 3 z.B. ja aber ohne weitere Module.
Man rennt da gegen Windmühlen.
Da sind meist die Sachen auf dem kleinsten Dienstweg mit den vorhanden Mitteln ohne irgendwelche Versuche an die IT zu treten, das schnellst und einfachste.

Der eigentliche Kunde ist dann da auch nur eine "kleine" Fachabteilung dort. Wenn die jetzt mit ihrer Fragestellung an die IT sich dort wenden haben sie vll. in einem Jahr ne Lösung. Oder auch gar nicht.
Wir sind Engineering, keine IT. Trotzdem wird da halt selbst was geskriptet und gebastelt etc. Nur je größer man da etwas aufzieht desto mehr macht man die IT da auf sich aufmerksam und das gibt eher Probleme als Lösungen...

 

[Tornhoof]

Persönliche Meinung bei 200 Access Dateien, egal ob mit binär Daten oder Ohne. Lass da Access sein, besorg dir eine SQL Server Express Version (die kann seit 2025 auch DB Größe 50Gb) und importier die Access Daten da rein.
Dann lass dir von Claude oder Codex ein 0815 crud Gerüst im C# mit .NET 10 bauen und setz darauf dein AG-Grid auf. Wieso die ganze MS Schiene? Geht am einfachsten mit dem Access Import (und ja läuft danach auch auf Linux).

Wenn du es noch einfacher haben willst, dann lass Claude ein MS quickgrid implementieren mit EF Core Anbindung, dann hast du Server Side Rendering und ein potentiell sehr schnelles Grid.

 

[chr1zZo]

Na da es wohl eh am Ende "Schatten IT" ist was hier betrieben wird, weis ich nicht ob es die Mühe wert ist. Klar, das Leben der Angestellen vereinfachen. Aber es gibt nicht umsonst IT Richtlinien / IT-Sicherheitsrichtlinien, auch wenn sie Bürokratie im Unternehmen bedeuten.

 

[JumpingCat]

Der Kunde ist eine Firma mit mehreren 10.000 MA... dementsprechend schaut da die IT-Landschaft aus. Man bekommt da nix ohne superkomplizierten Antrag, Begründungen, Freigaben durch div. Gremien etc., Man kann auch nix selbst installieren außer was per Intranet zur Selbstinstallation freigegeben ist. Python 3 z.B. ja aber ohne weitere Module.

Access/VBA-Projekt

Na wie schaut es dann aus mit solchen U-Booten? Access will man doch auch schon bei viel kleineren Läden loswerden weil das nicht skaliert und man da auch nie saubere Zugriffsmodelle aufgesetzt hat.

So, jetzt schon sehr viel Text und wahrscheinlich kann mir keiner mehr folgen...?

Das was du beschreibst ist ein simples Projekt wenn du nur suchen willst.

Ich geb mal als Beispiel das web-Framework von dem ich ein wenig Ahnung habe, ag-grid: https://www.ag-grid.com/example/

Mit $999 Minimumpreis pro Jahr? Aber gleichzeitig hat dein Arbeitgeber keine Resourcen für 1 Server oder so was?

Wenn du programmieren kannst (oder sagt man heute KI bedienen?), dann frag doch mal nach ob man Access endlich loswerden will.

Access zu erweitern halte ich für keine gute Idee.

 

[Benna]

Die ganzen Daten gehören in ein vernünftige Datenbank wie einen SQL-Server, Oracle, etc. importiert. Beim SQL-Server geht das sogar per Benutzeroberfläche in Access bzw. im SQL-Server selbst. Per ODBC-Connection sollte das aber auch mit jeder anderen Datenbank funktionieren. Bei der Gelegenheit auch schauen, ob das Tabellendesign taugt (Relationales Modell beachtet, Primäry Keys gesetzten, Index auf wichtigen Feldern gesetzt etc.). Ohne gutes Tabellendesign und eben grundlegende Performanceoptimierungen wird die Suche auch bei großen Datenbanken schneller langsam als notwendig.

Bevor man jetzt Daten auswertet, gehört zudem die Datenqualität geprüft, sonst kommt bei den Auswertungen erfahrungsgemäß ziemlich viel Müll raus. Und dann kannst du dir die Auswertungen eigentlich auch sparen.

Im Falle eines SQL-Servers kannst du sogar Auswertungen in Access bauen, auch als Formular, und die Daten dann direkt im SQL-Server abfragen. Der SQL-Server ist um ein vielfaches schneller als die kleine Jet-Datenbankengine, die unter der Access-Oberfläche vor sich hin wurstelt.

Oder natürlich, ihr lasst euch eine vernünftige Anwendung mit Datenbankanbindung bauen. Vibe-Coding wird für jemand ohne Programmierkenntnissen nur schwierig und mit viel Aufwand funktionieren. Zudem ist die Codequalität fraglich und niemand kann das Projekt später pflegen.

Mal meine 0,02€

 

[nutrix]

Oder natürlich, ihr lasst euch eine vernünftige Anwendung mit Datenbankanbindung bauen. Vibe-Coding wird für jemand ohne Programmierkenntnissen nur schwierig und mit viel Aufwand funktionieren. Zudem ist die Codequalität fraglich und niemand kann das Projekt später pflegen.

Das ist die einzig richtige Vorgehensweise. Schatten-IT rächt sich immer nach einer Zeit ganz schnell, und die Kosten für das Geradebiegen und Ablösen von Access ist dann meistens mit Projekt und Kosten deutlich teuerer, als wenn mal es gleich vernünftig macht.

Auch wenn du die E-Mail-Anhänge ins Filesystem auslagerst (richtig gedacht), können einige zehntausend Zeilen mit Textfeldern, Memo-Feldern und Indizes je nach Inhalt durchaus an die Grenze kommen – vor allem wenn das Archiv weiter wächst.

Auch einer der Gründe, warum dann Access, schneller als man denken kann, abgelöst werden muß. Ich hatte die letzten Jahre einige Access-Ablösungen direkt wie indirekt begleitet, und alle Lösungen, egal ob mit MS-SQL-Server, MariaDB/MySQL oder PostgreSQL waren deutlich besser und performanter.

Klar, eine Access-Lösung ist immer mal "schneller" umgesetzt, aber die Nachhaltigkeit ist, gerade bei Wachstum und Erweiterungen, nicht gut.

Wenn die jetzt mit ihrer Fragestellung an die IT sich dort wenden haben sie vll. in einem Jahr ne Lösung.

Ja, weil sie auch richtig planen, und nicht nur husch husch agiert wird. Gerade sowas wie Wachstum, Prognosen und Erweiterungen wird kaum eingeplant. Kückenlösungen führen langfristig fast immer zu Problemen.

 

[ch0815]

Ich danke für eure Einschätzungen. Die sind sicher gut durchdacht und sinnvoll. Einiges von dem Genannten übersteigt mein Wissen und meine Kenntnisse sowieso.
Bitte versteht aber, dass ich mich hier im Rahmen der Möglichkeiten bewegen will/soll/muss. Ich bin mir ziemlich sicher, dass, wenn ich denen nun vorschlage, sie müssten mind. einen Datenbankserver bestellen bei der IT (und monatlich bezahlen), dass das dann gleich abgeblasen wird.
KISS und Pareto dürfte hier die Devise sein. Und wenn die Suche paar Sekunden dauert, so what. Soweit ich verstehe werden da gelegentlich mal paar alte Sachen gesucht.
Da sind eure Vorschläge ein bisschen zu große Kanonen. Auch wenn die Spatzen vielleicht doch ein bisschen größer sind, als die vielleicht denken.

Ja, es steht z.b. MS SQL Server zur lokalen Installation sogar zur Verfügung. Aber der liefe dann halt lokal, nützt ja nix.

Ich versuche doch bei Access zu bleiben erstmal. Und wäre froh, wenn ich evtl. hier dazu Fragen stellen könnte, ohne dass ständig versucht wird mir das auszureden. Die Tatsachen sind nun mal so wie geschildert. In dem Rahmen möchte ich mich bewegen, sonst können wir es gleich bleiben lassen. Sich ständig "verteidigen" zu müssen macht dann auch keinen Spass.
Da muss man leider schon sagen das ist der Vorteil von KI. Die wird mir vll. vorschlagen es anders zu machen, hilft aber auch ohne Murren, wenn man die evtl. nicht so passende Lösung durchziehen will.
Was jetzt aber nicht heissen soll, dass ich die Einschätzungen hier nicht schätze etc. Ich möchte trotz KI eben nach wie vor echte Menschen fragen.

Das was du beschreibst ist ein simples Projekt wenn du nur suchen willst.

Genau, mehr soll es auch nicht sein.

Mit $999 Minimumpreis pro Jahr? Aber gleichzeitig hat dein Arbeitgeber keine Resourcen für 1 Server oder so was?

ag-grid war nur ein Beispiel zur Anschauung. Ich wollte das hier nicht ernsthaft einsetzen. Das hatten wir in einem alten Projekt von mir, da hätte der Kunde das auch gezahlt, sofern die Entwicklung nicht abgewürgt worden wäre.

vll. zur Verständnis: Wir bewegen uns hier in der Automobilindustrie. Hier wird gerade alles externe komplett abgewürgt. Es ist nichts weniger als eine Katastrophe.
Wir hier in der kleinen Firma sind sowieso demnächst alle arbeitlos. So siehts aus.

 

[nutrix]

Da solltest Du Dich an der Empfehlung von @chr1zZo halten, die klang so ganz vernünftig und durchdacht.

In dem Projekten bei mir wurde alles mit entsprechenden ETL-Tools gemacht, welche direkt Excel Dateien auslesen konnten.

Ergänzung (17. Juni 2026)

vll. zur Verständnis: Wir bewegen uns hier in der Automobilindustrie. Hier wird gerade alles externe komplett abgewürgt. Es ist nichts weniger als eine Katastrophe.
Wir hier in der kleinen Firma sind sowieso demnächst alle arbeitlos. So siehts aus.

Dann sollte Dir das doch eh egal sein, Du hast eh nichts mehr zu gewinnen. Let it be, tote Pferde kann man nicht reiten.

Bitte versteht aber, dass ich mich hier im Rahmen der Möglichkeiten bewegen will/soll/muss. Ich bin mir ziemlich sicher, dass, wenn ich denen nun vorschlage, sie müssten mind. einen Datenbankserver bestellen bei der IT (und monatlich bezahlen), dass das dann gleich abgeblasen wird.

Ich hab auch schon mehrfach Projekte abgelehnt, wenn sie vom Budget, Freigabe, Ressourcen kontra Ansprüche nicht umsetzbar waren. Und ich lebe immer noch. 😉 Für eine Murkslösung bin ich mir bis heute zu schade, und es ist überhaupt keine Schande, wenn man Grenzen erkennt und es einfach nicht mehr geht. Wenn sie Dir nicht mal eine lummelige SQL-Server DB zur Verfügung stellen können, sorry, man muß nicht jeden Mist mitmachen.

Ich weiß, Du siehst das jetzt alles aktuell aus einer technischen Sicht und versuchst es mit Deinen Mitteln umzusetzen. Aber Dein Problem ist jetzt hier nicht die Technik und das Zeugs dahinter, Du hast ein ganz anderes Problem, und das läßt sich so eben nicht lösen. Man muß lernen, als Umsetzer auch zu fordern, und nicht jeden Mist hinnehmen, der einem vorgesetzt wird. Zeugt eben meiner Meinung nach auch von Kompetenz im Berufsleben, die so nicht schadet. 😉