Delphi-PRAXiS - Delphi Switch Oracle auf MS SQL-Server

Hallo,

Zitat:

Zitat von toschmaster

Also was den Kosten/Nutzen-Wert betrifft sind wir Entwickler uns einig, dass dies in keinem Verhältnis steht. Deshalb ist auch meine Empfehlung diesen Schritt nicht zu gehen (und so wird das auch den Kunden weitergegeben).

Ausgetauscht werden muss "Direct Oracle Access 4.1.1" durch das SQL-Server Pendant. Desweiteren muss im Source entsprechende Oracle-Objekte ausgetauscht werden (ist klar diesen Aufwand muss ich selbst abschätzen weil nur ich den Source kenne). TQuery,etc. werden nichts benutzt. Läuft alles über die Packages und dann eben die erwähnten Oracle-Objekte mit deren Hilfe dann die Daten auf die GUIs gebracht werden.

Da eine Neuentwicklung nicht in Frage kommt (Die Anwendung ist so ja OK und eigentlich auch gepflegt aber Oracle eben anscheinend zu teuer im Betrieb (?)) wollte ich wissen wie einfach es ist eine bestehende Anwendung von Oracle auf SQL-Server zu trimmen (ohne Anpassungen am Source, nur der technische Switch) und dann die Möglichkeit einzurichten damit theoretisch Prozeduren auf dem MS-Server angesprochen werden können.

der letzte Absatz klingt ja so, als ob ggfls. beide Datenbanken funktionieren können sollten müssten (oder so) und bei Bedarf drehen wir den berühmtberüchtigten Schalter und schon gehts auf die andere Datenbank.

Können Dir die Datenbänker sagen, wie in Zukunft ein Aufruf der Datenbankroutinen auf der Datenbank aussehen wird? Können sie Dir sagen, ob ein Package eine Prozedur werden wird, also zahlenmäßig eine 1:1-Übersetzung? Oder gibt es eher eine 1:n-Übersetzung und wie groß wird dann n? Kann es Dir passieren, dass die Aufgaben, die heute durch einen Packageaufruf erledigt wurden in Zukunft durch mehrere Prozeduraufrufe zu erledigen sind? Wenn ja, musst Du das dann im Programm koordinieren?

Also mal so aus dem Bauch: Bedingt Kompilierung überall da, wo im Programm was geändert werden muss. Die Stellen zählen, die kompilzierteste raussuchen und testweise "Umbauen" (soweit es mit dem bisherigen Wissen geht). Die Zeit mal 2 * Anzahl der Stellen und gucken was da rauskommt. Dann die persönliche Erfahrung und Selbsteinschätzung zum Gewichten nehmen: Frei nach dem Motto: Darf's ein bisserl mehr sein oder auch ein bisserl weniger (Bist Du schnell? Sind alle Änderungen nach einem Schema umzusetzen oder sehr individuell? Wie ist der Testaufwand? ...) oder ist das Ergebnis vollkommen utopisch. Ist letzteres der Fall, weitere Informationsbeschaffung, um den Aufwand besser abschätzen zu können und wieder von vorne beginnen.

Diese Form der Einschätzung kann aber auch gigantisch nach hinten losgehen, also Vorsicht.

Mit meinem Wissen über die von Dir zu pflegende Software würde ich mich allerdings mit dieser Methode nicht an eine Schätzung herantrauen.