Zitat von juergenz
Beitrag anzeigen
Die Probleme liegen nicht an oder bei Microsoft sondern bei den Leuten die die Anwendungen programmieren.
Wenn man mich in Ruhe machen lässt kann ich mit Java oder Mono mindestens genausoviel Unheil anrichten.
Ich denke dass der MS-SQL-Server eines der besser abgehangenen Softwareprodukte aus dem Hause MS ist - alleine weil das eine Business-Anwendung ist an deren Stabilität und Fehlerfreiheit die Existenz etlicher Unternehmen hängt. Es gibt etliche MS-SQLs die Terabytes an Daten für tausende Benutzer bereit stellen. In einer ordentlich designten Umgebung kein Problem.
Das Problem fängt dann an wenn diese Systeme Programmieren in die Hände fallen die da mit Gewalt versuchen, ihren eigenen Kopf durchzusetzen. .NET ist abwärtskompatibel minus Fehlerbeseitigung und minus sicherheitsrelevante Änderungen, d.h. wer was für .NET 2.0 programmiert hat kann sich drauf verlassen dass das unter .NET 4.0 immer noch funktioniert - es sei denn da wurden Sachen benutzt die von MS als fehlerhaft oder sicherheitskritisch eingestuft und geändert wurden - das ist seitens MS sauber dokumentiert welche Funktionen das betrifft.
Und dann gibt es die Superprogrammierer die das Konzept "Abwärtskompatibel" nicht verstanden haben und bei der Installation hart auf die x-te Nachkommastelle der Version des .NET prüfen - und teilweise noch auf die Sprachversion - und wenn sie nicht das finden was sie erwarten da einfach ihre Version ins System reinbügeln.
Ähnliches kann man mit dem SQL fabrizieren. Warum man sich auf eine bestimmte Version in einer bestimmten Sprache kapriziert wissen nur die Programmierer. Es gibt etliche Softwares die - in Grenzen - mit verschiedenen Versionen klar kommen, im Business-Umfeld ist es gängig, die Anwendung und den SQL getrennt zu verkaufen bzw. die Anwendung in einen bereits vorhandenen Server zu installieren - der SQL ist darauf ausgelegt, die Daten verschiedener Anwendung sauber getrennt zu verwalten. Ein kleines Beispiel ist WAGO, deren Konfigurator ist in zwei Versionen erhältlich, mit SQL und ohne wenn auf dem Rechner (oder irgendwo im Netzwerk) schon ein SQL läuft, in dem Fall liefert WAGO eine Anleitung und ein SQL-Skript damit man selbst die Datenstrukturen im SQL anlegen kann, dann sagt man der Applikation einfach wo der SQL wohnt und fertig ist die Laube.
Solche Sachen wie Computername gleich Kontoname wären für einen Programmierer mit zwei Zeilen Code im Setup abzufangen - wenn diese Bedingung zutrifft gehe ich garnicht erst in die Installation sondern werfe eine entsprechende Fehlermeldung im Klartext und breche die Installation ab, das zu programmieren geht sicher schneller als nachher so einen KB-Artikel zu verfassen - abgesehen davon dass ich diese Fälle von meinem Support fern halte.
Kommentar