Wo eigentlich ANFANGEN mit der Entstörung?

Spekulationen und Wetten bringen uns nicht weiter.
Herr Greif könnte in seiner Verzweiflung unüberlegte Dinge tun, die uns allen dann ein schlechtes Gewissen machen.  

als PKs in ihrer Datumsbank? :-)  

Html einzufügen.. :-)

Glaube nicht, dass wir das von außen so sehen können. Das könnte alles mögliche sein.

Jedenfalls gab es mal früher Schwierigkeiten durch Unicode <-> ISO Zeichen-Konvertierungen. Was nun welche Probleme verursacht hat, weiß ich nicht. Ich hab's nur gehört :)  

Wobei es meiner Meinung nach recht außergewöhnlich wäre, dass man nicht numerische IDs als primary key verwendet.  

über Firebird kommt

Class.forName( "org.firebirdsql.jdbc.FBDriver" );
cn = DriverManager.getConnection( "jdbc:firebirdsql://MyDbComputerNameOrIP/myDatabasePath/myDatabas­eFile", dbUsr, dbPwd );  

naja...
ich weiss, dass sich eine Ariva-DB-Häuptling drum kümmert.. und das Prob auch löst...
Wenn Herr Greif nach so langer Zeit nich noch warten kann.. selber schuld...

der obige Ausschnitt ist die nach einem Bewertungsversuch mit Ergebnis Fehler 20  vom Server aufgebaute Seite... bezogen auf den Abschnitt.

brennender Vogel sein :) So wie Dein Profilpic...  

429: die Bewertungstasten scheinen mir doch ein JS zu starten...
430: nicht in Dokumentenbasierten Datenbanken... und da bin ich mir sehr sicher.. dass zumindest die Thread-bezogenen Inhalte in einer solchen stehen...

MAc: ???? der Fehler tritt auf, wenn andere Greif bewerten wollen.. was da Greifs Browser soll?? Und die Com zwischen Ariva und dem Browser ist eigentlich auch nicht sooooo sehr DB-connection-bezogen.. ich hörte da ma was von HTML murmeln :-)

JavaScript != Java

Und McMurphy hat einfach Tante Google nach
Java Datenbank
oder so befragt und den erstbesten Code hier reingehauen :)  

;-))  

zu 1) achne... hmmm... dann wollen wir das mal - hoffentlich - besser ausdrücken. Java Implementation meinte ich (vereinfacht) die Runtime (425). Das JS gibt ja nix als ein Objekt an die Runtime (434). In dem Objekt muss wohl zwangsweise die ID des zu bewertenden enthalten sein. Da Java (und auch JS) soweit ich weiss - das ist nicht mein Gebiet) in der aktuellen Version Unicode verwenden, sollte es hier kein Prob geben. Wenn aber der Server (der ja nicht unter Java läuft) mit Unicode nichts anfangen kann, wäre dein 423 ein starker Fehlergrund. So aber die Zeichensätze der DB und der Java-Parts passen, sollte beim Ausführen des JS nichts schiefgehen.

zu 2) das war mir auch klar.. und das noch aus nem Lehrbuchbeispiel wie man ne SQL-DB konnektieren könnte...  

Javascript ist etwas vollkommen Anderes als Java. Ich bin davon ausgegangen, dass Du die serverseitige Programmiersprache meinst. Ich konnte als User bisher nicht erkennen, ob der/die Server Java-Server sind oder reine Apaches.
Was gegen eine Java-Server-Geschichte spricht sind die Chart-Diagramme bei Ariva. Da gäbe es andere Module (bzw. Servlets), deren Clientausgabe in Form von HTML, CSS und JS ich wahrscheinlich wiedererkannt hätte. Aber hier hat man ein eigenes Modul geschrieben.

Die Konstruktion der Sprachen selbst hat keinen Einfluss auf den Zeichensatz. Der Programmierer legt die gültigen Zeichenkodierungen fest, wenn sie ausgeliefert werden. Er empfängt die Dateneingaben von Usern und muss sie auf Plausibilität prüfen (und dabei säubern). Ein Leerzeichen kann dann schon mal schnell mit einer *replace() oder trim() funktion verloren gehen...

Vielleicht ist auch das schon die gesamte Magie.  

Noch vor Encoding-Problemen tippe ich auf eine automatische Leerzeichenentfernung, sofern tatsächlich Usernamen als primary keys bei der Datenbanksuche verwendet werden.  

Es gibt den Apache Webserver, der via Connector mit dem Apache Tomcat (Java Servlet Container) kommuniziert. Über die Tomcat-Servlet-Schicht kann man, wenn es das technische Design erlaubt, direkt über die Java-API auf das jeweilige DB-System zugreifen - wie es Kronios in seinem Beitrag (#1425) beschreibt. Es ist zwar nicht elegant, für ein Gästebuch oder ein Online-Forum jedoch relativ schnell implementiert (inklusive der Opensource Ajax-Bibliotheken). Ich hatte diesbezüglich auch schon Probleme mit der Konvertierung von Zeichen und musste feststellen, dass die DB einen anderen Standard-Zeichensatz verwendete als die JVM der Unix-Distri.
Da die Herren "MODS" nix über die System- und Softwarearchitektur rausrücken, können wir hier wie auch bei den Aktien nur spekulieren... ;)  

Da gibt es viele Java-Open-Source Tools, welche die Grafiken rendern und diese dann zum Client schicken. Selbst Banken machen davon Gebrauch. Falls Interesse besteht, werde ich auf meiner Festplatte oberhalb des Halses Indizes anlegen..  

1439.. hätt ich nicht dagegen gewettet...

Zeichensatz meinte ich 1348 oder 899 oder so.. weiss nich ob die Zahlen stimmen.. also erweitert europäisch oder us straight.. da hat kein Progger einfluss... die sind genormt..

zur serverarchitektur... vorn stehen - ich sag mal GUI-Servern und nenn sie FE - Teile, die die Browser mit HTML versorgen.. ob das nu Apaches sind.. weiss nich.. ich tippe eher auf was anderes... das könnt man aber recht leicht feststellen, welche Server den HTML liefern, da muss man nich ma hacken...
dahinter steht die Architektur mit den Daten, welche die FE mit Content versorgen. Hier vermute ich, dass die Thread-Inhalte in Dokumenten-DAtenbanken stehen. Also No-SQL.
Gleichzeitig bin ich so gehässig zu vermuten, dass (Teile der) Userdaten in SQL-Datenbanken stehen.
Die FE-Teile müssen auf alle Fälle den Content woanders holen... sonst wären zwei feststellbare Tatsachen nicht möglich.
1) Bei Belastung sind die Datenbanken nicht konsistent. DAs kann ein Apache nicht :-)
2) Die Wartezeiten bei Belastung schwanken stark. Das heisst die Content-Server saugen Daten - dauert bissl - und versuchen sich zu syncen - dauert lang .
Weiter: Es gibt Situationen, in denen man auf Post zugreifen kann, die nicht in der Thread - Übersicht sind.. und andersrum... d.h. NON-ACID.
Da HTML-gebunden FE-Teile grundsätzlich Thread-integer sein müssen, können sie nicht auf eine DB zugreifen, die NON-ACID ist.
Und es wär ja doof, wenn alle Content-Management-Systeme - was für ein hochtrabender Name - verkaufen würde... und Ariva hätt nen Apache-Cluster... und sonst nix :-)

stellen. Besonders für Load Balancing ist das eine gute Sache. #
Aber so war das nicht gemeint von mir.  Es ging mir bei einem "reinen Apache" nur um das Synonym eines Webservers, der auf Nicht-Java-Basis läuft (z.B. PHP betrieben).

Wenn der Server (die Admins) die Info nicht freiwillig preisgibt (auf Fehlerseiten, etc.), dann ist es alles nur Spekulation.  

...ja sogar bei den Banken!!!  

sharepoint oder iie sind nicht ma php :-)...

worums mir ging.. Schichtenarchitektur möcht ich das nicht nennen... aber es ist ne mehrstufige Architektur...  

beenden oder auslagern.

Teras wird es uns danken, wenn wir hier nicht talken :)  

Dazu kann ich nicht viel beitragen (php).
Ich bin seit 12 Jahren in der Software-Entwicklung im Bankenumfeld tätig, und bisher durfte ich immer noch den guten "alten" Tomcat in der Entwicklungsumgebung hernehmen, welcher auch produktiv eingesetzt wird...

Wir lesen uns, gute Nacht!  

Nicht so gut für kleine, speicherschwache VServer im Netz aber für dedizierte Blades auf jeden Fall...

Good Night!  

Freiwillig kriegen wir hier fast überhaupt GAR nichts. - Aber es ist ja nicht verboten, nur lange genug seinen Blick auf denen (nicht freiwillig) offenbarten Veränderungen IN der (ebenfalls nicht offenbarten) ursprünglichen Veränderung zu belassen...

Fehlerhafter Umgang mit OMISSION-Marks ist immer kritisch! - Und von dem charmanten Zeichen, das im Beitrag #1407  www.ariva.de/forum/Ich-habe-bei-00-23-Uhren-378449?page=56#jumppos1407  erneut auf seine Schreibbarkeit getestet wurde, war ja auch schon HIER  www.ariva.de/forum/Hallo-zusammen-Teil-5-7-378449?page=13#jumppos343  ein wenig die Rede.

Es hat hier NIE eine nachvollziehbare Veranlassung vorgezeigt worden, die gegen ihren Willen verunsichtbarten IDs auf "vert"~ PER-nominiert wieder sichtbar zu machen an Statt, wie das jeder ENTSTÖRER gemacht haben würde, sie auf ihre originäre und völlig System-unschädliche DE-Nominatio mit der nicht VERTICALEN sondern HORICONTALEN Tilde in ihrem Namen zu RE-nominieren!

Aber manche Entwickler kommen halt mit dem Unterschied zwischen horicontal und vertical nicht zurecht. - Man darf vermuten, dass das ganz die Selben sind, die auch ein völlig harmoses GRAPHEM in einem NICK-Name nicht von einem COMMANDO in einem BEFEHLS-String zu unterscheiden vermögen.