meiner Arg...
1) (Vermutung, aber ziemlich gesichert): es handelt sich um SQL-Datenbanken... also ACID. Für die Post wär das ala Google nicht nötig, aber für die Richtigkeit der Daten zu jedem Zeitpunkt (hau rein Teras).
2) davon auszugehen, dass Ariva nur einen Server hat..is ähm... Milchkuh...
3) ergibt sich daraus logisch das Prob, dass Posts hängen können, weil andere Daten, welche die Grundlage für die Posts sind (sein sollten)... wichtiger sind... also rin mit denen...
4) muss Ariva Geld verdienen (der GRÜNDER herbei).. also Werbung machen.. das kostet Power... aber spart dem User Geld.... schliesslich zahlen die Affen für ihre sinnlose Werbung...  (für den Gründer: auch Werbetreibende sind Leute, die für Ihre Werbung zahlen).
5) schicken die Datenlieferer ihre Daten, wann sie wollen... drum isses in der Zeit bissl dicht...
6a) die Daten wollt ihr aba... also Schnauze...
6b) ich sehe Optimierungspotentiale... aber das würde zu technisch...
Zusammenfassung: das ganze Prob ist komplex...  

 

 

wenn man nach folgender Meldung natürlich nicht den angegebenen
Zeitraum wartet, sondern weiterklickt...immer mit fadem Begeschmack...

Ihr Beitrag ist noch nicht abrufbar. Wir versuchen es in ca. 15 Sekunden noch einmal.

sondern das Post-Forum aufrufst, z.B. hier also links unten Talkforum...
scheints zu klappen...
Da ich nu sicher weiss, dass es SQL-Datenbanken sind... und auch welche...
vermute ich.. ohne es derzeit nachweisen zu können, dass die verteilt laufen.
Klickst Du auf die eine Art, sagt die Datenbank interessiert mich nich, Deine Anfrage wird woanders bearbeitet, kommste dummerweise vor dem db-commit auf die selbe-- rollback..
ich hatte gehofft swa gibt auf #976 ein paar Infos... aber vielleicht grübelt er ja noch :-)

Eine ganz ähnliche Rück-Meldung hatte ich mir in meinem Beitrag #882 auch von cs erhofft:  www.ariva.de/forum/MIN-String-Length-378449?page=35#jumppos882

cs: "it's not a bug, it's a feature... "

die "sogenannte" Indizierung" von Texten ist - wie DU weisst - ein klein wenig ein Problem... zum Beispiel dieser hier mit seinen Kronios-Punkten....
eine ACID-Datenbank mit einem Algorithmus zu versehen, der über "Indizierung" eine erhöhte Trefferquote ermöglicht - und das wohlgemerkt im Vergleich von der zu Dir genannten NSQL-Datenbank - ist nicht möglich... hmmja.. schon... aber Google haut halt irgendwas raus, Hauptsache viel... und hier isses wichtig Hauptsache richtig...
eine "c (konsistente)" Datenbank mit ner Suche zu verknüpfen, die nicht ACID ist, wäre Katastrophe, wird aber in der Cloud kommen.
Man könnte, falsl hier einige Probs mit den technischen Details haben, die Frage stellen: Lieber nix, als Scheisse, oder lieber viel und Scheisse dabei....  

http://www.ariva.de/forum/An-ANDERER-Stelle-378449?page=10#jumppos264

eben NICHT...
oder schon... egal..

Ich möchts mal krass sagen: die sog. "Indizierung" von Daten KANN bei konsistenten Datenbanken "C" (damit haben wir AIB wech) nicht so schnell funktionieren. Bei konsistenten Datenbanken kann sie auch nicht so GUT funtionieren... weil Daten eben unterschiedliches Format haben, die Indizierung aber kann nur in einem Format suchen... ja... man "behebt" das durch entsprechende Formatwandlung... GENAU DIE verursacht die Fehler...
Das genaue Gegenteil zu Google oder Amazon... der Datenbank ist das Fomat egal, sie muss ja auch nicht für Konsistente Daten sorgen... da wird alles!! in einem!!! technischen Format gespeichert... da ist die Frage der Formatwandlung egal.... damit funktioniert auch die sog. Indizierung...  

abends zu diesen Verzögerungen kommt. Wartungsarbeiten?  

gelesen.

Es ist ein Verteilungsproblem. Die Daten werden nicht da gelesen, wo sie gespeichert werden. Daher müssen sie erst mal dahin, wo sie gelesen werden. Daher sind auch #978 bzw. #980 Gegenstand des Problems und völlig richtig in der Darstellung.

#975 bzgl. der doppelten Fehlermeldung ist ein Bug, den ich noch finden muß. Die Tatsache, dass sich Beiträge bereits in der DB befinden, sie aber nicht angezeigt werden, kann darauf basieren, dass das Speichern des Beitrags wegen zu hoher Last (Anzeige der Meldung: "Das Speichern Ihres Beitrags wurde aufgrund zu langer Wartezeit abgebrochen.") abgebrochen wurde, weil die Antwort nach einer gewissen Zeit nicht kam. Der Beitrag wurde in der Zeit aber schon gespeichrt. Daher führt ein erneutes Speicher oder Prüfen des Beitrags zu der Fehlermeldung.

Vielen Dank auf jeden Fall für die Hinweise.

In #926  www.ariva.de/forum/BUG-Reporting-378449?page=37#jumppos926  und auch
in #951  www.ariva.de/forum/Entstörungs-DURCHSATZ-378449?page=38#jumppos951 war bereits kurz an unseren "Fehler melden"-LINK Beziehungs-weise -BUTTON erinnert.

Diesen habe ich jetzt bemüht, um die unten ersichtliche, INCONSISTENTE Error-Message als BUG zu reporten, da durch diese logisch inconsistente Error-Message nicht nur das Beitrags-EINFÜGEN, sondern auch schon die Beitrags-VORSCHAU geblockt wird:

Aber könnte es vielleicht sein, dass ihr die Verfügbarkeit der Google-Server überschätzt?
Ihr benutzt einige Verlinkungen auf js-Google-Bibliotheken im Ajax-Context. Könnte nicht auch die Ursache eurer Datenbankprobleme mit den Netzwerkverbindungen bzw. der Erreichbarkeit von Google-Servern zusammen hängen?  

Die BoardMail-Abstimmung ist beendet - und hat ausschließlich PRO-Stimmen ergeben.
Die Einladung geht nachher bei 8:00 Uhren 'raus.
Hoffen wir, dass er die Einladung annimmt!

Entstörung ist TEAM-Work...
Der olle Teras.

wie in 976 und 980 vermutet handelt es sich um verteilte SQL-Datenbanken. Das hat swa in 986 auch bestätigt. Hier geht es um die Posts...

Die Darstellung der Daten und das "Zumischen" der Google-Sachen hat mit diesen Datenbanken nix zu tun.

bei Calls und Puts auf den DAX ...  

7,64 €

7,65 €

7,37 €

+3,79%

 

Aber bei RBS, was ja für den Trader maßgebend ist, funzt es immer noch nicht  :-(((((((

 

http://www.ariva.de/forum/...High-428557?search=nightfly#jump11844320       erscheint z.B und
dann ist man in der Warteschleife, wenn es sein muss, für Stunden...
nicht immer, aber heute schon mehrmals
manchmal hat er aber auch z.B. 17 neue Beiträge ohne Beanstandung
eingereiht

Die Registered Shares o.N. des iShares Silver Trust (WKN: A0JMD6;
ISIN: US46428Q1094; Symbol: SLV) rangieren hier bei uns auf ARIVA unter
"iShares Silver Trust ETF SUJ YM" (siehe das unten documentierend anhängte Photo).

Dass dieser iShares Silver Trust hier bei uns als "iShares Silver Trust ETF" bezeichnet wird, mag ja noch angeh'n, denn schließlich ist das Ding ja ein Exchange-traded Fund.

Was aber hat es mit dem Rätsel-haften "SUJ YM" auf sich, und woher stammt das seltsame Symbol "SLVNV"? - Und wieso hat die schrille Gurke weder Düsseldorfer noch Frankfurter Curse? - Weltweit heißt das Teil iShares Silver Trust und sein Symbol ist SLV.

Ich werde den seltsamen Consistenz-Fehler auch per "Fehler melden"-Button reporten, und zwar von DIESER  http://www.ariva.de/quote/simple.m?secu=889601  Seite aus...

 

aktualisiert. Damit wird ja das ganze Traderspiel sinnlos.  

Kaum Error-mäßig reportet und documentiert - schon hat der iShares Silver Trust sein correctes Symbol und seinen richtigen Namen (siehe das Photo)...

Und speciell an swa:  
Ein ganz herzliches Willkommen in unserer Gruppe!

endlich ein Ende?  

endlich ein Ende?

Ihr Beitrag ist noch nicht abrufbar. Wir versuchen es in ca. 15 Sekunden noch einmal  

endlich ein Ende?

Ihr Beitrag ist noch nicht abrufbar. Wir versuchen es in ca. 15 Sekunden noch einmal

Ihr Posting existiert bereits in unserer Datenbank.Ihr%20Posting%20existiert%20bereits%20in%20unserer%20Da­tenbank.Ihr%20Posting%20existiert%20bereits%20in%20unserer%20Date­nbank.