INVESTOX-Forum

Hallo zusammen

Zitat

Original von Georgmartin
ein IB Mitarbeiter meinte Investox hat manchmal probleme die API 9.10 zu erkennen.

Bei mir war es so.

Gestern Abend war es soweit, nachdem es keine Probleme gab auf der Entwicklungs-Maschine, auch der Testrechner gar keine Schwierigkeiten machte beim Upgrade auf API 9.10 - habe ich die Produktion umgestellt. Wohl wissend, dass man ein Backup haben sollte :]

Für mich überraschend (PS 1) trat der Fall ein "Die Komponente Tws.ocx oder eine Ihrer Abhängigkeiten ist nicht richtig registriert.", und ich konnte weder RTT für IB starten, noch bekam das ORM eine Verbindung zur TWS.

Also habe ich alle oben von mir selbst beschriebenen Schritte ausgeführt, und auch die Versionen Verglichen wie von Herrn Knöpfel oben beschrieben: es hat nichts geholfen. Der Restore war fällig. Dann habe ich es erneut und etwas akribischer versucht. Bis ich wieder aufgegeben haben und das zweite Mal den Restore gefahren habe um 2:30 heute Nacht (Acronis sei dank ohne Aufwand in 19 Minuten erledigt, übrigens; bin direkt nach dem Restore-Start schlafen gegangen und heute morgen war alles heil). Auf der Produktions-Maschine, die heute morgen wieder life sein sollte!

Fazit: ich habe nun eine Produktions-Maschine, die nicht kompatibel ist zu irgend einer meiner Test- oder Entwicklungsmaschinen. Und ich kann frühestens am nächsten Wochenende erneut testen, wie man die TWS API 9.10 mit Investox zum Laufen bekommt

Vielleicht hat jemand hier im Forum schon weitere Erfahrungen gemacht oder möglicherweise kann Herr Knöpfel genaueres sagen, wofür die TWS.ocx gebraucht wird und warum IB meint, dass gerade Investox Schwierigkeiten hat, die API 9.10 zu erkennen?



PS 1: überraschend, weil ich jede Version und jeden Update erst auf den Test/Entwicklungsrechnern mache und jeden Schritt genau notiere und nachvollziehen kann, auch Monate später.

Hallo Bernd,
bei mir läuft die API 9.1 auf 2 Rechner. Ich mache es schon seit sehr langer Zeit immer so, daß ich die alte API deinstalliere und dann die neue draufspiele.
Was IB-Mitarbeiter im Zusammenhang mit Investox & API erzählen würde ich generell mit großer Skepsis begegnen, der API-Support wird meis Wissens nach in den USA gemacht.

(RTT-IB 2.83 + API 9.1)

Da war noch was, das hier (s. unten).

"Bei Problemen mit der API hilft es oft, die Datei "TwsSocketClient.dll" im System32-Ordner zu überprüfen. Diese sollte dieselbe Version haben wie die "TWS.ocx"

Vuego

Hallo,

in der aktuellen Installationsversionen der IB API fehlen offenbar einige Dateien, die zum Betrieb der API notwendig sind. Damit hat nicht nur Investox Probleme, sondern jedes Programm, das die TWS.OCX der API verwendet (Siehe: http://www.interactivebrokers.com/cgi-bi…e=/2/42570.html)
"Check to see if you have the folders x86 Microsoft.VC80.CRT and x86 Microsoft.VC80.MFC in your WINDOWS\WinSxS"

Mit der Installation des C++ 2005 Redistributable Package sollte dies behoben werden können:

[URL]http://www.microsoft.com/download…&DisplayLang=de[/URL]

Nach der Installation dieses Packages ist nochmals die API Installation durchzuführen.

Viele Grüße
Andreas Knöpfel

Hallo,

Zitat

Sooo viel Testaufwand für die Katz

wieso für die Katz?
Die guten Systemumfeldkonfigurationsbeispiele, die Bernd hier bereits geliefert hat sind vom feinsten!
Und ohne exakte Notizen kann man auch keine schnelle Lösung im Problemfall erwarten!
Vuego

Hallo Herr Knöpfel

Das finde ich sehr konstruktiv, danke! Ich werde es diese Woche sichten und sehen, was man machen kann.

Zitat

Original von Vuego
Da war noch was, das hier (s. unten).

"Bei Problemen mit der API hilft es oft, die Datei "TwsSocketClient.dll" im System32-Ordner zu überprüfen. Diese sollte dieselbe Version haben wie die "TWS.ocx"

Hatte ich gecheckt. Sie hatten die selbe Version.

Ich habe auf beiden PC's VB 2005 installiert, vielleicht geht es aus diesem Grund bei mir.
Die API 9.1 habe ich nach VB2005 draufgespielt. Auch hierfür sind Aufzeichnungen gut :-))

Hallo Vuego

Da könnte was dran sein: auf meiner Entwicklungs-Maschine gibt es Entwicklungsumgebungen und Debugger.

Und eigentlich wollte ich auf der Testmaschine eben keine Entwicklungsumgebung, um solche Problem finden zu können vor der Produktiion. Leider musste ich seinerzeit wegen dieser Probleme die Entwicklungsumgebung auch auf die Test-Maschine ausrollen. Damit ist meine Test-Maschine wie damals befürchtet eben nicht mehr produktionsnah genug, und ich kann solch ein schwerwiegendes Problem erst auf der Produktionsmaschine bemerken, denn

nur auf der Produktionsmaschine gibt's natürlich keine Entwicklungsumgebung.

Hallo Herr Knöpfel

Vielen Dank für den Hinweis mit dem C++ Redistributable. Nun konnte ich das TWS API 9.10 installieren und es gibt keine Probleme mit der TWS.OCX.

Bitte lesen Sie trotzdem den allgemeinen Teil, weil ich noch eine Bitte habe:


Hallo zusammen

Ich wurde mehrfach gefragt, warum ich auf meiner Produktions-Maschine keine Entwicklungsumgebung haben will und mich da so "anstelle". Ich dachte, dieses Wissen wäre Allgemeingut; es scheint nicht so zu sein, also versuche ich es mit dieser Erklärung:

Zuerst: eine Entwicklungsumgebung ist nicht zu verwechseln bitte mit einer Laufzeitumgebung wie dem C++ Redistributable, welches ich nun aufgrund des Hinweises von Herrn Knöpfel installiert habe.

Eine Entwicklungsumgebung stellt alle Möglichkeiten zur Verfügung, die ein potentieller Angreifer bequemst nutzen kann, um die Kontrolle noch einfacher zu übernehmen. Alle Entwicklungstools wie Debugger, Scriptsprachen oder gar Compiler, Symbolic Reassembler etc. sind das perfekte Mittel. Wenn sie erst installiert sind, sind sie praktisch nicht mehr zu kontrollieren.

Ein ungebetener Gast wird natürlich zuerst nachsehen, ob ein Compiler oder eine Scriptsprache etc. auf einem Rechner installiert ist. Dann geht alles viel leichter für ihn. Sagen wir, der Compiler ist das Hauptangriffs-Ziel. Danach kann ihn nichts mehr aufhalten.

Seit es die neuen Gesetze gibt, liesst man darüber nicht mehr viel im Web. Einen sehr alten Artikel gibt es doch (hier) , welcher das Problem darstellt. Die zugrundeliegende subversive Hacker-Philosopie kann man sich selbst ableiten nach Lektüre der Informatik Bibel (Gödel, Escher, Bach - ein endloses geflochtenes Band von Douglas R. Hofstadter erste Auflage 1979 engl, deutsch gibt es auch, man findet es manchmal günstig auf Flohmärkten). Dieses Buch fällt so aus dem Rahmen, dass es sich nicht wird verbieten lassen, und doch alles erklärt.

Ich darf noch hinzufügen, dass aus den genannten Gründen in den meisten grossen Unternehmen Compiler auf Produktions-Maschinen absolut tabu sind.

Nun komme ich zu meiner Bitte an Herrn Knöpfel: wenn man nicht wegen externen Indikatoren wie hier beschrieben gezwungen wäre, die Entwicklungsumgebung mindestens bis auf die Testmaschine auszurollen, so könnte man die Testmaschine als exakte Kopie der Produktion fahren (wie es ja auch sinnvoll wäre). Dann würden Probleme wie diese mit der TWS.ocx bereits im Test auffallen, nicht erst in der Produktion! Bitte versuchen Sie, die externen Indis so von Investox abzukoppeln, dass kein Compilerlauf nötig wird für neue INV Updates! Diese Problematik hat letztlich dazu geführt, dass mein ganzer Testaufwand an dieser Stelle für die Katz war, wie Gerasan oben spottete.

Edit: Typo