War bei einer Instandhalteranwendung in der Voest Linz / Stahl auch sehr beliebt und ist es vermutlich immer noch.
Wenn eine Anlage zu reparieren ist muss es schnell gehen und sehr viele Menschen fassen gleichzeitig Materialien aus. Die nn Delphi entwickelte Lösung lief einfach. Selbst als 'das Netzwerk' (ein Teil) ausfiel wurde die
DB Datei einfach auf einen anderen Server kopiert und es konnte weitergearbeitet werden.
Bei großen Schuppen wird gerne auch probiert mit SAP zu arbeiten, damit Replikation wird eingespart. Im SAP war was auf eine Delphi Maske mit TabControl passte in SAP 20 Dialogen abgebildet (im SAP). Eigenentwicklung in ABAP wurde abgelehnt, da selbst der einfachst gestaltete Prototyp besser lief als die Standardtransaktionen und das kann nicht sein.
Deswegen kommt man ohne Delphi nicht durch oder zumindest .net hilft schon. Oft sind politische Entscheidungen der Enabler für andere.
Solche straighten Lösungen sind beliebt solange die
DB zumindest nicht zu oft und per Anwendung kann reorganisiert werden. Was mit wieder zum Punkt bringt, dass die
DB schnell zu sichern sein sollte und gegebenfalls from Scratch der Generierungsprozess eilig reproduziert werden muss können. Wenn mal was wäre, dann wird auf den Codezwerg hingehackt von den Benutzern.
OT:Zumal man seit dem gestern Rider
IDE habe probiert neben Go-Land muss ich sagen langsam bilden sich auch komfortable Alternativen für die Entwicklung auf der Serverseite mit gelegentlichem
GUI heraus.
Ersatzhardware muss nicht immer gleich schnell sein. Das ist zwar heute nicht mehr so das Thema. Je größer die Datenbestände des schwieriger das Backup usw... und damit singt auch die Willigkeit ein Backup ...
50k neue Sätze im Jahr auf einer großen Tabellen und du weißt warum die Oracle so viele Optionen hat bei so manchem Statement.
nutzen ein Zukauftool. (Letztendlich eine "SingleFileEngine", welche Single/Multiuser, Compress/Crypto und SimpleIndex/SQLselect sauber und wirklich schnell selbst löst)