mir stellt sich die frage woher du weißt welche row in table_B zu table_a gehört.
wenn du diese frage beantworten kannst dann hast du auch deine query.
hm stimmt mit der woche hast recht ..
ja ich werd das wohl erstmal bissl austesten müssen! Danke schonmal
wenn jemand anderes noch ideen hat bitte schreiben
debian inside schrieb:
Hallo
ich hab in ner Datenbank mit Eigenschaften die zu einer ID zugeordnet sind und
diese wird relativ groß.
Ist es schneller einen Datensatz mit allen Eigenschaften in eine Spalte zu schreiben und diese dann mit Volltextsuche zu suchen (B) oder für jede Eigenschaft einen eigenen Datensatz einzufügen (A)
...
Der Inhalt eines Feldes sollte immer "atomar" sein - Also eine einzige klare Information enthalten. Alles andere macht früher oder später Ärger. Was machst du z.B. wenn du eine Eigenschaft entfernen willst? Dann musst du erst so einen Substring/Replace o.ä. Krampf durchführen. Über die die Geschwindigkeit solltest du dir keine Sorgen machen, dafür gibt es Indizes.
So hat sich alles aufgeklärt! Nun funktioniert es!
Man sollte auch sicherstellen, dass in den auszulesenden CLOB Feldern, auch wirklich Texte enthalten sind!
bye Saxony
ok, da hilft wohl nur noch 2 weitere tabellen
Fragen_text
Fragen_bild
und dann in der fragen tabelle statt ein feld "type" das dann entweder 1 ( text) oder 2(image) enthält...
und dann ein lookup in der jeweiligen tabelle...
naja ob sich aber das lohnt dafür extra 2 tabellen anzulegen,
eine andere alternative wäre in dem text feld "use_image" einzutragen, und wenn der text dort drin steht dann das bild aus der tabelle "fragen_bild" zu nehmen...
Bei MSSQL oder andere Datenbanken Funktioniert auch das:
auf den abgegebenen Insert
pqUpdate->SQL->Add( "Insert ...");
...
pqUpdate->ExecSQL();
Folgt die Abfrage der vergebenen ID
pqUpdate->SQL->Add( "SELECT @@identity AS ID");
pqUpdate->Open();
if ( !pqUpdate->Eof) {
m_ID = pqUpdate->FieldByName("ID")->AsInteger;
}
Hiho,
so naja als erste Annäherung zur Lösung lese ich die WINFOLDER\ODBC.INI aus.
Dabei parse ich die Sektion "[ODBC 32 bit Data Sources]".
Und von den Einträgen wie "testdb=SQL Server (32 Bit)" nehme ich nur die Namen (testdb) um meine ComboBox zu füllen.
Wähle ich nun aus meiner ComboBox einen Namen aus kann ich den dann direkt an z.B.: ein TQuery weitergeben. Das funktioniert nun.
Naja so richtig das gelbe vom Ei ist es aber noch nicht.
bye Saxony
Hi ihr zwei, vielen Dank für eure Antworten. Vielleicht versteh ich es einfach nur nicht oder ich bin zu naiv um zu glauben, dass es besser ginge. Ich will wirklich von der Steuerung Daten raus ballern, und nach Möglichkeit nichts pollen.
chris_phz schrieb:
Ich würde über OPC von dem Rechner, auf dem die Datenbank läuft die Daten aus der Steuerung holen.
Verstehe ich das echt falsch, für was läuft auf dem Ding nen Webserver mit OPC und soweiter wenn ich danach doch wieder vom SQL-Server aus mir die daten holen muss. Ich würde gerne von der Steuerung weg Daten raus bringen.
BorisDieKlinge schrieb:
libnodave sps /c++ bibliothek...und ado für c++ ^^
Das hab ich nicht ganz verstanden, wie läuft das konzeptionell ab? Das läuft dann auch auf nem separaten Rechner der dann über diese Lib auf die SPS zugreift?
Vielen Dank, helft mir bitte vom Schlauch auf dem ich steh
besserwisser schrieb:
man liest, dass postgresql auf mehreren cores besser skaliert als mysql.
_Viel_ besser.
es unterstützt mehr sql features als mysql, wobei hier mysql schneller aufholt als postgresql erweitert wird.
Klar, Postgres ist ja in punkto Standardunterstützung schon wesentlich näher an der Feature-Completeness dran, als MySQL. Und auch wenn es natürlich stimmt, dass InnoDB hier wesentlich stärker ist, so hat dies doch auch eine Menge Nachteile.
Das wirst Du wohl selbst machen müssen.
Du hast sicher eine Schleife durch die Datesätze und schreibst die ins Grid.
Dann teile eben den Datensatz und schreibe eine 2te Zeile ins Grid.
Wenn die Primärschlüssel automatisch durch ein Autoincrement erhöht werden, dann lass diese Spalte doch einfach aus. In der Insert-Projektion (col1, col2, ...) eben die Primspalte nicht mit angeben und in der Select-Projektion SELECT col1, col2 eben auch nicht.
wie der fehler schon sagt.. du hast eine abfrage aus ein Excel sheet gemacht... welcher aber nur "readonly" ist... Versuch doch mal ne INSERT INTO abfrage auf das excel sheet zu machen????
überdenke deine Datenbankdesign? Allein deine erstes Problem mit den unterschiedlich langen spalten, lässt schon auf ein ungewöhnlich Design schliessen.. was möchstest du den genau tun....???
Nein, den AutoInc-Wert darf man gar nicht mit angeben.
Ich vermute eher, dass ein Primärschlüssel fehlt. Mach doch aus der Kartennummer bitte mal den Primärschlüssel.
Wenn es das nicht ist, mach bei den Stringliteralen mal richtige Anführungszeichen, statt der Hochkommas. Paradox ist manchmal etwas seltsam.
Hi
Ich kann die Tage mal mein altes ODBC Zeug auf meine Website laden, dann kannste dir den Wahnsinn mal anschauen
lol, ja das wäre sehr nett
Danke für den Tipp, habe glaube ich schon was feines gefunden. ADO sieht sehr viel schöner aus bisher Trotzdem wäre es mal gut zu sehen, wie du dieses Problem mit RecSets erledigt hast.
Danke, danke für deine Hilfe
Grüsse
ReduX schrieb:
Hi,
...
Es soll wie gesagt nicht so aufwendig werden, ich dachte da an so einen Parser der Befehle wie INSERT UPDATE DELETE entgegennimmt also nicht so umfanggreich.
MFG ReduX
Versuch doch erstmal nur einen SQL Parser zu schreiben, der deine Kommandos korrekt interpretiert ohne was zu machen. Das wird schon spannend genug
möchtest Du einen Verlauf (Historie) speichern oder einfach nur die aktuellen Daten?
Bei der Historie würdest Du ja einfach die neuen Werte hinzuschreiben.
Beim letzteren einfach per Update die Zeit und den Kurs der jeweiligen Aktie aktualisieren.