Hi,

villeicht hilft das

http://chepri.com/mysql-innodb-corruption-and-recovery/

oder das

http://forums.cpanel.net/f5/help-mysql-dead-refuses-restart-68355.html

Viel Glück!
f_igy

Hi,

falls Du Testdaten brauchst:

Pi mit 1 millionen Stellen hinter dem Komma

Gruß
f_igy

Hi,

stimme Abt zu. Möglicherweise ist XML was für dich

xml (Transact-SQL)

oder aber ein generisches Datenmodell mit Schlüssel-Wert Paaren

Attribute–value pair

Gruß
f_iyg

aber bei mir werden auch Dezimalzahlen als ergebnis vorkommen

ja, aber kommen Sie im konkreten Testfall vor? Führ das SQL doch mal in der Konsole aus und sieh Dir das Ergebnis an. SQLite hat ja bzgl. Typen eine recht eigene Sicht auf die Welt. Anders als viele Andere DBs wird dort ja vieles als Text gespeichert und/oder implizit konvertiert...

j.

Hm,

varchar (10,2) kenne ich auch nicht als gültigen Datentypen. Auserdem kann man 1,5 + 3,2 + 4,3 = 9 natürlich nach Int casten...

f_igy

Schau mal da:

101 LINQ Samples

Hi,

kann es sein, dass die Summe Deiner Werte sich als Int darstellen läßt, weil zufällig alle Zahlen eine "glatte Summe" ergeben?

Gruß
f_igy

Hi,

falls Du - wie Programmierhans das vorschlägt - das Problem auf der Datenbank lösen möchtest, würde ich von "NOT IN" abraten und auch dort eher "EXCEPT" (bzw. "MINUS" in Oracle) oder aber einen "LEFT JOIN" verwenden. Lange IN-Listen können ziemlich langsam werden und NOT ist bei den meisten DBs nicht Index untersützt.

Gruß
f_igy

Hi,

TCP ist nicht dafür gedacht eine bestimmte Latenz zu garantieren, sondern um sicherzustellen, dass alle Pakete beim Empfänger ankommen. Alternativ könntest Du UDP nehmen, dass aber keine Zustellung der Pakete prüft.

Gruß
f_igy

Hi,

nicht unüblich ist dafür auch in der Tabelle ein gültig-von und evtl. auch gültig- bis datum zu setzen. Bei einer Änderung wird der neue Datensatz mit dem aktuellen Datum gefüllt. Falls man ein Bis-Datum verwendet wird dieses beim neuen Satz auf High-Value, beim alten auf das Gültig-Ab des neuen Satzes gesetzt (offenes Intervall). Entspricht Kimbles slowly changing dimension vom Typ 2 (SCD2). Das Bis-Datum ist eigentlich überflüssig (es sei denn man will auch Löschen können), hat aber den Charme die aktuell güligen Sätze leicht ab gültig-bis = high-value erkennen zu können und ermöglicht zudem Zeitraum bezogene Auswertungen.

Das kann man gut auch mit Triggern machen, was den Vorteil hat, dass auch manuelle SQLs mit erfasst werden. Nachteilig kann hier die Performance bei Massenupdates sein. Bei einer Dialoganwendung ist das aber selten ein Problem.

gruß
f_igy

Ähem,

ist das nicht etwas kompliziert? Was spircht denn gegen meinen simplen Vorschlag einfach den laufenden Strom zu durchsuchen?

f_igy

Hi,

wenn ich Dich recht verstehe möchtest Du die Daten pivotisieren. Dies ist keine SQL Standard Funktionalität, wird aber von Oracle unterstützt:

ORACLE: Pivot and Unpivot

Alternativ geht so was Ähnliches in Oracle auch mit Listagg:

ORACLE: LISTAGG

Oder natürlich mit dem Selfjoin wie von "witte" beschrieben. Das hat den Charme, dass das Ansi-SQL ist, wird aber bei mehr Spalten irgenwann unleserlich und langsamer als PIVOT (bei Oracle).

Gruß
f_igy

Hi,

ich denke, Du wirst den Stream so lange unstersuchen müssen bis Du sicher bist, ob der zu ersetzende String enthalten oder nicht enthalten ist.

Pseudocodemäßig sowas in der Richtung vielleicht?

i=-1
repeat
  readStream(inByte)
  i++
until(inByte != suchString[i] || i=suchString.length())
case
  when i=0 //erstes Zeichen passt schon nicht -> also direkt das Zeichen
    return(inByte)
  when i=suchString.length() //alle passen, also den ersetzString
    return(ersetzString())
  else // suchsString passt bis zur Position i, also bis dahin zurück
    return(suchString().substr(1,i)+inByte)
end

Gruß
f_igy

Hi,

enthält die Datei auch die Schema Informationen? Wenn nein geht das so nicht

http://msdn.microsoft.com/de-de/library/yfxbc3by(v=vs.110).aspx

Gruß
f_igy

Kreative DB-Namen wie PROD, TEST, ENTW ....

Hi,

hast Du in der Tabelle irgendwo einen Default Wert definiert? Diese werden dann anstelle von NULL verwendet. Wenn nein würde ich mal nach Besonderheiten bei der BLOB-Verabeitung suchen. So kann Oracle z.B. zwei BLOBs nicht ohne weiteres Vergleichen.

Gruß
f_igy

Hi,

falls Deine Manipulation nicht zwingend in c# passieren muss könntest duch auch einfach die Daten per utility exportieren:

http://msdn.microsoft.com/en-us/library/ms162802.aspx

Bei vielen db-Systemen ist das der performanteste Weg.

Gruß
f_igy

Hi,

ich würde in's Blaue hinein einfach mal alle 1000 Inserts ein Commit machen.

http://msdn.microsoft.com/en-us/library/esdw1h9d(v=vs.100).aspx

Gruß
f_igy

Hi,

lt. Doku

TOP (Transact-SQL)

geht das mit TOP(n), also

SELECT TOP(10) SUM(Wert) FROM Tabelle ORDER BY Datum GROUP BY...

Ist ziemlich unterschiedlich von andern DBMS

SQL - Select first 10 rows only?

Gruß
f_igy

Hi,

Money ist im Gegensatz zu Decimal kein ANSI SQL Datentyp. Wenn es keinen zwingenden Grund gegen die Verwendung gibt würde ich eher den ANSI-Typ verwenden.

Gruß´
f_igy

Hm,

ich denke eher sowas in der Richtung:

USE databaseA;
GO
BEGIN TRANSACTION;
BEGIN TRY
    DELETE FROM Test
    Insert Into Test VALUES ('test','test','Hast','test','test'); 
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
END CATCH;

IF @@TRANCOUNT > 0
    COMMIT TRANSACTION;
GO

Gruß
f_igy

Hi,

daDa ich eine Tabelle komplett lösche und dann erst Insert mache und wenn dann beim Inser-Query ein fehler kommt bleibt die tabelle leer und das will ich vermeiden, sodass wenn der insert - query falsch ist ich noch die alten datensätze habe.

ist ein doch durch genau eine Transaktion ohnehin gewährleistet. Einfach den Delete und den Insert ausführen, wenn es zu keinem Fehler kam COMMIT, sonst ROLLBACK.

Das sollte doch genau das sein, was Du willst.

Gruß
f_igy

Hi,

offenbar hat MSSQL keine Funktion dafür (wie z.B. Oracle mit LISTAGG). Ich fand eine Lösung mit XML-Path

How to simulate the MySQL group_concat function in MS SQL Server

aber vielleicht solltest Du Dir auch mal LINQ ansehen

How to: Group Query Results (C# Programming Guide)

Allerdings könnte ich mir denken, das die Straßenliste sehr lang werden kann, was zumindest dem Erzeugen einer temp-Tabelle in der DB entgegen stehen kann.

Ich würde also noch einnmal darüber nachdenken, ob eine Matrix wirklich die richtige Lösung für Euer Grundproblem ist.

Gruß
f_igy

Hi,

das geht z.B. mit den analytischen Funktionen:

OVER Clause (Transact-SQL)

SELECT ROW_NUMBER() OVER(PARTITION BY id ORDER BY value) FROM table

Gruß
f_igy

Ach,

dann schau doch mal hier:

Walkthrough: Saving Data from Related Data Tables (Hierarchical Update)

Ich hab's beim Überfliegen zwar nicht verstanden, aber vielleicht hilft es Dir. Alles in allem bin ich mir nicht so sicher, ob es für die Interaktion mit Datenbanken immer so hilfreich ist Table-Adapter oder EFs zu verwenden. Die versprechen zwar alles einfacher zu machen, bereiten aber auch oft Kopfzerbrechen...

Gruß
f_igy

Achja,

vielleicht hilft das ja?

How to: Set the Order When Performing a Hierarchical Update
How to: Set the Order When Performing a Hierarchical Update

Gruß
f_igy

Hi,

könnte daran liegen, dass Du die beiden Inserts seit gestern in unterschiedlichen Transaktionen durchzuführen versuchst. Innnerhalb einer Transaktion sieht man auch nicht committete Daten, die außerhalb der Transaktion nicht zu sehen sind.

Wie man das im TableManager steuert habe ich aber keine Ahnung. Wenn Du den Code von gersten noch hast kannst Du ja mal ein diff machen und nach Transaktion oder dergl. suchen...

Gruß
f_igy

Hi,

das entspricht der Auflösungstabelle zwischen Rolle und Tabelle. Rechte können m.E. natürlich unterscheidlich sein (lesen, schreiben, löschen, ...). Ich fand grade dies:

Rollen sind keine Gruppen
Berechtigungssystem - Design korrekt ?

Gruß
f_igy

Hi,

naja, eine Matrix scheint mir da nicht das Richtige. Normalerweise verknüpft man eine USER- und eine Rollen-Tabelle über eine Zwischentabelle zur auflösung der n:m-Beziehung (einer user kann mehrere Rollen, eine Rolle mehrere User haben).

Die meisten DB-System haben solche Berechtigungsystem. Falls Du ein eigenes Programmieren willst würde ich dringed zum Studium eigehender Literatur zum Thema Berechtigungsystem raten. So wie Du das planst ist das etnweder so genial, dass bisher noch niemand anderes drauf gekommen ist, oder aber die meisten haben das Kozept verworfen, weil es zu Problemen führt...

Gruß
f_igy

Hi,

Datasets kann man total einfach nach XML Schreiben und auch Lesen.

Laden eines 'DataSet' aus XML (ADO.NET)

Wenn Du lediglich die Daten dauerhaft speichern willst, keine spezielle DB Funktionalität benötigst und keine riesigen Datenmengen hast würde ich daher XML nehmen. Kann man vor dem Speichern auch noch mit GZIP klein machen, falls die Dateigröße ein Problem darstellen sollte. Zudem bietet Linq ja auch einiges von dem, wozu man sonst gerne SQL verwendet.

Create Table aus einem Programm ist zumindest ungewöhnlich. In aller Regel benötigen klassische SQL-Datenbanken kostante Datenstrukturen für ein effizientes Arbeiten. Bei SQL-Lite sieht die Sache evtl. etwas anders aus, da der Optimizer dort sehr dynamisch zu arbeiten scheint. Mit No-SQL DBs kenne ich mich nicht aus, so weit ich weß sind die gut für große Datenmengen wenig oder nicht strukturierter Daten geeignet.

Gruß
f_igy

Hi,

wenn Du nur Spalten anfügen willst kannst Du das mit "alter table add column".

SQL: ALTER TABLE Statement

Vielleicht ist aber eine Datenbank für Dein Problem nicht ganz das Richtige? Evtl. ist eine XML-Datei flexibler?

Gruß
f_igy

Hi,

geht mit beiden Vorschlägen, MINUS heißt in manchen DBs "except".

Gruß
f_i´gy

Huhu,

hast Du nach der Änderung ein COMMIT durchgeführt? Sonst ist die Änderung nur in der eigenen Transaktion zu sehen.

Gruß
f_igy

Hallo zusammen,

SQL ist eine deklarative Programmiersprache, d.h. man beschreibt das gewünschte Ergbenis, nicht den Weg, auf dem man dorthin gelangt.

Deklarative Programmierung

Den Weg bestimmt die Datenbank selber, in aller Regel steht ihr dazu ein mehr oder minder schlauer Optimizer zur Verfügung. Der Optimizer bezieht dazu verschiedene Faktoren ein, z.B. vorhandene Indexe, Erwartete Datenmengen, Qualität der Filterung der WHERE-Clause, etc. Wichtig sind dafür Informationen über die Daten, die in aller Regel aus den ++Systemstatisken ++ kommen. Wenn diese Statistiken nicht repräsentativ sind kommen meist sehr schlechte Zugriffspläne mit schlechter Performance heraus.

-> Aktuelle Systemstatisken sind für performante SQL Abfragen wichtig!

Unter dieser Bedingung wählt der Optimizer in aller Regel einen guten Plan. Im komkreten Fall filtert er also vor dem JOIN. Falls die Statisik aber nicht erwarten lässt, dass der Filter nur 10 von 1Mio. Datensätze herausfiltert, verwirft der Optimerzer dieses Vorgehen. Also nochmal:

-> Aktuelle Systemstatisken sind für performante SQL Abfragen wichtig!

Zwischen der Bedingung im ON und im WHERE gibts übrigens einen Unterschied, falls man LEFT JOIN verwendet.

Stimmt, auch für RIGHT und FULL OUTER JOIN. Generell sollte man auch beim INNER JOIN die JOIN Bedingung in die ON-CLause, den Filter in die WHERE-Clause schreiben, da das SQL dadurch lesbarer wird. Auf die Performance hat das keine Auswirkung!

SELECT *
FROM A
JOIN B
  ON A.ID = B.ID
WHERE A.SNAFU = 'hä?'

Manche Optimizer haben gelegentlich Probleme den richtigen Pfad zu finden. Dann hilft machnmal die Neuformulierung des SQL, z.B. mit NESTED TABLES:

SELECT *
FROM 
( SELECT *
  FROM A
  WHERE A.SNAFU = 'hä?'
)A
JOIN
( SELECT * 
  FROM B
) B
  ON A.ID = B.ID

Das ist dann aber was für selten Spezialfälle und sollte nur von Leuten gemacht werden, die sich mit der entsprechenden DB gut auskennen.

Gruß
f_igy

Aha,

scheint also tatsächlich um Berchtigungen zu gehen. Da m.E. MSSQL keine Rechte auf Zeilenebene aussprechen kann würde ich das nach wie vor über unterschiedliche User-Views auf die Master-Tabellen regelen. Das Synchronisieren von Datenbanke ist meiner Erfahrung nach nämlich selten eine Quelle für ausgelassene Stimmung... Falls Ihr dennoch mal einen Versuch wagen wollt würde ich mal nach Change Data Capture (CDC) suchen. Folgendes habe ich da gefunden:

http://www.mssqltips.com/sqlservertip/1474/using-change-data-capture-cdc-in-sql-server-2008/
http://technet.microsoft.com/en-us/library/bb522489(v=sql.105).aspx

Empfehlen würde ich das aber nicht!

Gruß
f_igy

Hm,

wozu braucht Ihr denn die untergeordneten DBs? Soll das für eine Art von Berechtigungssytem sorgen? Ich würde nur die Master DB Tabelle vorhalten und ggf. Views für die einzelnen untergordneten DBs anlegen. Auch MSSQL beherrscht unter bestimmten Bedingungen DML auf Views:

CREATE VIEW (Transact-SQL)

Gruß
f_igy

Hi,

ich würde in TBL3 zwei Felder einfügen, FK und FK_ART. Das 1. Feld enthält den Foreign Key, das 2. die Information, auf welche Tabelle dieser verweist. Gefällt mir besser als Deine Variante, da damit auch die Tabellen Tab.4..n auf die Tab3 Verweisen können, ohne dass Du weiter Spalten anfügen musst,

Als Variate kann man auch die PKs in Tabelle 1&2 (..n) gemeinsam vergeben, so dass die Referenz in Tab.3 immer eindeutig ist.

Beide Varianten gehen aber nur eingschränkt, wenn Du Constraints verwenden möchtest.

Gruß
f_igy

Hi Björn,

Deinem Fazit kann ich mich voll und ganz anschließen.

Schönen Tag uns sonniges Wochenende wünscht
f_igy

Huhu,

dieser Aussage

Zu erst die wenigst häufig wechselnden Spalten und zu letzt die am warscheinlichst häufigst unterschiedlichen Spalten.

muss ich leider auf das heftigste Wiedersprechen! Ein Index ist dann besonders wirksam, wenn das Filterkriterium möglichst weit vorne im Index steht. Bei mehreren Kirterien sollte das Kriterium mit der höchsten Frequenz vorne stehen. Dadurch wird beim Zugriff die Ergebnismenge schon durch den Filter auf das erste Feld erheblich eingschränkt!

bitte immer die Abfragen ohne "*" machen

kann ich hingegen voll und ganz unterstüzen. Je weniger man Selektiert desto besser. Viele DB-Systeme beherrschen auch sog. Index-only Zugriffe, d.h., dass falls ein Index alle benötigten Informationen enthält, gar kein Zugriff auf die Tabelle passiert!

Auch das hier

Wenn eins ein Full-Tablescan macht, must du optimieren.

stimmt nicht immer. Wenn Du alle oder fast alle Sätze einer Tabelle lesen willst ist der Relation Scan eben der beste Zugriff, den man nicht weite optimieren kann!

Ach es gibt einfach zu viele möglichkeiten eine Datenbank zu Optimieren um dir die passende zu liefern. Einfach mal ein gutes Buch lesen.

Ist ein guter Tipp! Einfach nur Indexe über Tabellen zu streuen bringt in der Regel wenig. Wichtig sind vor allem ein gutes DB-Design und vernünftige SQLs. Grundsätzlich kann man annehmen, dass mehr als drei Indexe auf einer Tabelle verdächtig sind. Das heist natürlich nicht, dass es auch Fälle gibt, wo es sinvoll sein kann 30 Indexe auf einer Tabelle zu haben. Allerdings kenne ich kein Beispiel 😉!

Gruß
f_igy

Hi,

bei VIEWs gibt es auf Zahlreichen DB-Systemen unterschiedliche Einschränkung bzgl. schreibender Statments. Schau mal in die Doku deiner DB, was da so steht.

Gruß
f_igy

Hi,

muß genau in der Reihenfolge sein, sonst klappt es nicht.

deutet darauf hin, dass Deine Klammerung nicht ordentlich die ORs und ANDs unterteilt. Da der Optimizer die Reihenfolge der Auswertung dieser Argumente nach
DB
DB-Version
Systemstatistik
Reihenfolge der Argumente im SQL-Statement

festlegt wirst Du möglicherweise beim nächsten Update-Statistik, einer anderen SQL-Datenbank oder einer neuen MS-SQL Version andere Ergebnisse bekomme. Deine "Lösung" ist. m.E. keine!

Gruß
f_igy

Hi,

gern geschehen. Folgender Beitrag könnte für dich auch interessant sein:

Lücken in Aufzeichnungen füllen

Dein Problem ist eigentlich ganz ähnlich und könnte durch ein Feld Folge_Revision, dass per default mit einem LowValue (oder NULL) belegt ist gelöst werden. Dafür musst Du natrülich die Tabellen und Bewirtschaftung anpassen. Macht aber das SQL einfacher und schneller.

Gruß
f_igy

Hi,

eine moderne Lösung ist die Benutzung Analytischer Funktionen, die in den meisten modernen SQL-DBs eingebaut sind. In Deinem Fall ist

http://msdn.microsoft.com/de-de/library/hh231517.aspx

vielleicht hilfreich. Alternativ geht auch ein Self-Join

select * from
(select [Part ID], MAX (Revision) Revision from Parts group by [Part ID]) maxi
join Parts einz
  on  maxi.[Part ID] = einz.[Part ID]
  and maxi.Revision  = einz.Revision

oder so ähnlich. Aber lies dir lieber mal den Artikel bei MS durch.

Gruß
f_igy

Hi,

ich denke, dass liegt dann daran, dass der Effekt bei der Umwandlung in der Datenbank passiert. Der Debugger weiß davon natürlich nichts. Das sich Prepared-Statements anders verhalten hätte ich nicht erwartet. Allerdings ist ein Bulk-Copy ja für große Datenmengen gedacht, sodass es da gut sein kann, dass andere Routinen genutzt werden, als bei Einzel-SQLs.

Gruß
f_igy

Hi,

Float ist eine Gleitkommazahl, Decimal ein exaktes Format. Ich nehme an, das die Unterschiede durch Rundungsdifferenzen kommen.

Probier mal

DECIMAL(9,7)

und schau nach, was an Nachkommastellen zu sehen ist.

Gruß
f_igy

Hi,

kann es sein, dass das MS SQL Sever Mangement Studio 10 zur Anzeige sich lediglich die Anzahl der Sätze der Ergebnismenge und dann die ersten paar Datensätze holt? Wenn Du zum Ende der Ergnismenge springst, dauert das dann lange? Wenn dem so wäre liegt es dann einfach am fetchen und übertragen der Datensätze.

p.s.: wie mein Vorschreiber finde ich das SQL im Übrigen reichlich merkwürdig. Ist das selbstgehäkelt oder stammt es aus einem Genreator?

Gruß
f_igy

Hi,

also ohne das SQL im Detail zu verstehen erscheint mir der Code ziemlich merkwürdig. Offenbar verwendet die Abfrage Subselects, die bei größeren Datenmengen gerne mal ein Problem darstellen, da dadurch synchrone IOs auf der Datenbank provziert werden. Auch die Verwendung von UNIONs finde ich etwas überraschend...

Außerdem erscheint das Ganze für die Fragestellung, ob mindestens ein Datensatz in der Query enthalten ist, für mich etwas aufwändig.

Ich würde da die SQLs doch lieber selber schreiben, da Dein EF das wohl nicht so gut kann.

Gruß
f_igy

Hi,

m.E. ist Ansatz 2 besser, da er sprachlich den Bereich JOIN-Bedingung und WHERE-Bedingung trennt. Inhaltlich ist das bei INNER JOIN letztlich egal. Bei OUTER JOINs muss man allerdings aufpassen, da sich die WHERE-Bedingung auf die Gesamtergebnismenge bezieht, während eine Einschränkung in der ON-Bedingung sich auf die Ausgangsmenge/Tabelle angewendet wird.

Gruß
f_igy