Goos

Dann geht das mit einem gleichgearteten Statement. ^^ Du musst nur die Einheiten rausnehmen und durch die Disziplinen ersetzen. Goos

Über den Mirroring Mechanismus des SQL Servers ist das zum Teil möglich. Du brauchst für einen automatischen Failover noch einen Witness Server wie du ja schon richtig erkannt hast. Einschränkung hierbei ist aber, dass nur auf dem Principal aktiv gearbeitet werden kann. Gleichzeitiges Schreiben auf mehreren Servern ist also nicht möglich. Ausserdem ist das Mirroring nur mit 3 Servern möglich (Principal, Mirror, Witness). Hinzufügen von weiteren Servern is also nicht. Das Schreiben auf mehreren Servern ist wenn möglich eher zu vermeiden, da passende Konfliktlösungen je nach Anwendung recht komplex sind. Prinzipiell ist das aber über die SQL Server Merge-Replikation machbar, wenngleich diese auch nicht ganz einfach zu Planen und Implementieren ist. Generell lässt sich zumindest viel von deinen Anforderungen verwirklichen, da die Replikation auch mit dem Mirroring verknüpfbar ist. In dem Fall sprechen wir aber von einem Projekt welches du, so wie ich das momentan einschätze, nicht ohne externen Berater und Projektleiter angehen solltest. Abschliessend würde ich dir (vielleicht auch nur aufgrund der eher schwammigen Anforderungen) zu einem Database Mirroring mit Witness Server raten. Goos

Na ein 2005er SQL Server ist doch schon ok, der kennt ne PIVOT Funktion. Die Einheit brauchst aber für deine Aufgabe. Sie stellt ein Gruppierungskriterium dar. Du willst ja schliesslich alle Weiten addieren. Sogesehen würde ich dir raten, im Ergebnis nur die Zahlenwerte zu halten und dafür in der Tabelle tblDisziplin eine Spalte Einheit einzufügen. Du kannst dann ein Statement mit PIVOT Funktion darauf loslassen. Das würde wohl in etwa so ausschaun: SELECT Name, Vorname, Klasse, [m] AS 'Weite', [MIN] as 'Zeit' FROM (SELECT a.Name, a.Vorname, a.Klasse, Ergebnis , b.Einheit FROM tblSchueler a INNER JOIN tblDisziplin b ON b.id = a.Disziplin ) p PIVOT (SUM(Ergebnis) FOR Einheit IN ( [m], [min]) ) AS pvt Goos PS: du solltest aber kein a und b Alias verwenden, so wie ich das hier getan hab ... is ein ganz schlechter Stil, erhöht aber meiner Meinung nach bei einen so kurzen Statement die Übersicht :-)

Punkt 1: Dein Tabbellendesign ist suboptimal ... allein schon weil du Ergebnis mitsamt Einheit in einer Spalte notierst Punkt 2: Du hast dein DBMS noch nicht genannt Goos

Hi net-tobi, nach Ausführung des Statements bleibt nichts "reales" übrig, wenn man mal vom Execution Plan im Cache absieht. Du kannst es dir sogesehen gerne als virtuelle Tabelle vorstellen. Goos

Moin net-tobi, ich werd mal versuchen die von die genannten Tabellen und Parameter zu verwenden. So wie du es beschreibst müssen also der wert KO aus Tabelle 2 und ein Wert V2 aus Tabelle 4 für den entsprechenden Datensatz übereinstimmen um gezählt zu werden. Vom Prinzip her musst du nur all deine Tabellen joinen, auf übereinstimmende Vergleichswerte prüfen und das dann zählen. Es könnte also in etwa folgendermassen ausschaun: SELECT COUNT(TabUC.KO) --zählen FROM TabRA INNER JOIN TabUC ON TabRA.UC = TabUC.UC INNER JOIN TabObjekt ON TabRA.Objekt = TabObjekt.Objekt INNER JOIN TabObG ON TabObjekt.Art = TabObG.IDGR WHERE TabUC.KO = TabObG.V2 --vergleichen Goos

Hi net-tobi, letztendlich ists deine Sache, wie du das machen willst. 1,5 Stunden halte ich allerdings für heftigst viel. Das sollte eher eine Sache von Sekunden sein bei 60000 Datensätzen. Wenn du hier allerdings keine Beispieltabellen posten willst, dann seh ich auch wenig Chancen dir ein entsprechendes Beispielstatement zu präsentieren. Goos

Hi Azubi-Tigerente, es gibt auch ein SQL Server 2008 Management Studio Express mit dem du das machen kannst. Goos

Hi net-tobi, du brauchst dafür wirklich keinen Cursor und solltest den an der Stelle auch besser nicht verwenden, dabei bleib ich Wenn du mir mal kurz ein paar Spaltennamen und relevante Werte aus den 3 Tabellen postest, dann mach ich dir dazu auch mal ein passendes Statement. Vielleicht bringt dich das dann ja beim Thema SQL ein wenig weiter. Goos

Na man kanns ihr sagen. Standardmäßig steht der two digit year cutoff auf 2049. Alles über 49 bekommt also ein 19tes Jahrhundert verpasst, der Rest ne 20. Dieser Wert lässt sich aber auch ändern. Zugegebenermassen ists aber etwas sicherer, wenn man vierstellige Jahreszahlen verwendet. Goos

Hi subsurfer, die Password Option gibts nicht in der GUI. Du musst dazu in deinem Wartungsplan nen T-SQL Statement Task auswählen und dein Backup dort händisch eintragen (BACKUP DATABASE TEST TO DISK ... blablabla WITH PASSWORD= '123') Zu erwähnen ist dann vielleicht noch, dass mit gesetztem Passwort auch die Wiederherstellung über die GUI wegfällt. Das geht dann auch nur noch über ein SQL Statement. Goos

Ok, das klingt nicht gerade nach einer Wahnsinnssicherheit. In dem Fall würde ich dir dazu raten, beim BACKUP DATABASE die Option WITH PASSWORD zu verwenden. Das bietet dann mindestens mal soviel Sicherheit wie das Packen mit 7Zip mitsamt Passwort. Zu Beachten ist jedoch, dass diese Option in einer zukünftigen SQL Server Version wegfallen wird. In allen SQL Server 2008 Versionen inklusive R2 ists allerdings noch enthalten. Du darfst dir dann in ein paar Jahren also vielleicht was neues einfallen lassen. Goos

Hi auch, du brauchst da nichts umwandeln. Der String 771203 wird beim insert in ein Datetime Feld automatisch gewandelt. Das einzige was du vorher noch machen solltest, ist die Reihenfolge im Datum vorzugeben. In deinem Fall ein SET DATEFORMAT YMD Goos

Davon würde ich abraten. Dein SQL Server kann das auch mit nem mengenbasierten Ansatz lösen, was in den meisten Fällen die bessere Variante sein dürfte. Prinzipiell brauchst du wie schon erkannt eine Unterabfrage. Der Übersichtlichkeit halber würde ich beim SQL Server 2005 aber eher zu einem CTE raten. Das Aufsummieren über Jahr und Monat macht man dann für gewöhnlich mit einem Cast des Datums in einen String von dem man die Tage abschneidet. Das könnte dann irgendwie so ausschaun: WITH myCTE (Benutzer, Monatsstunden) AS ( SELECT Benutzernummer ,CASE WHEN SUM(Stunden) > 2 Then 2 ELSE SUM(Stunden) END as 'Monatsstunden' FROM t_stunden GROUP BY Benutzernummer, LEFT(CONVERT(varchar(30), Datum,112), 6) ) SELECT Benutzer, SUM(Monatsstunden) as 'Stunden' FROM myCTE GROUP BY Benutzer Goos

Moin, versuch doch nochmal darzulegen, wieso du das Ganze machen willst. Die Maschine auf der dein SQL Server läuft sollte doch entsprechend gesichert sein. Die Backups der DBs welche dann erstmal auf der gleichen Maschine liegen sind folglich ebenso sicher. Wenn du dann noch auf Bänder sicherst, dann werden auch die mit Sicherheit entsprechend sicher gelagert. Fazit: kein weiterer Schutz der Backups notwendig. Goos PS: es gibt beim Backup Database Befehl des SQL Servers auch eine Passwort Funktion, diese ist allerdings abgekündigt und sollte nicht verwendet werden.

Hi net-tobi, mach dir keine Gedanken des If Befehls wegen. Ein relativ einfaches Select Statement reicht für deine Zwecke aus. Mit deinem Cursor und der If Abfrage bremst du deine Datenbank nur aus. Goos PS: Da du aus der VBA Programmierung kommst, denkst du halt vermutlich noch nicht mengenorientiert.

Es gibt zur Laufzeit deines Triggers noch keinen entsprechenden ContactId Eintrag in der contactExtention Tabelle. Vielleicht erklärst mal, wie bzw. wann der angelegt werden sollte und was du dabei unter automatisch verstehst. Goos

Ich hab zwar vermutlich keine Loesung, finds aber irgendwie interessant. Kannst du vielleicht auch noch irgendwie darlegen, welchen Sinn das Ganze machen soll? Ich tu mir beim gedanklichen Nachvollziehen etwas schwer, weil kein konkreter Anwendungsfall genannt ist. Goos

Nu schaem dich erstmal dafuer, dass du im ersten Post nicht dein Problem geschildert hast. Wenn du schon meinst, du wuesstest in welche Richtung es geht, dann kann man damit oftmals recht wenig anfangen Dein Problem ist die Abarbeitungsreihenfolge des Querys Hier nachzulesen Das Group by wird vor dem select angewandt, was erklaert wieso das Alias welches du im Select vergibst nicht schon im Group by bekannt ist. Das heisst dann fuer dich, dass du deine Funktionen im Group by nochmals aufrufen musst. Goos

Du bist schon auf dem richtigen Weg. Deine Funktion kann in deinem Beispiel doch nur nicht wissen woher sie Zaehldatum nehmen soll. Versuch mal etwas in der Richtung von: SELECT Spalte1, Spalte2, dbo.VZA_FORMATDATE(ZaehlDatum,'YYYY') from MyTable Goos

Versuch mal sp_helpdb Goos

Na ich mein den Fall 3. Da wird berechnet ueber die Datensaetze welche durch Start-Ende eingeschraenkt wurden und nicht ueber alle 10 Millionen. Wenn du also Start auf 1900 setzt und Ende auch 2010, dann wirds etwas langsam werden mit den Berechnungen. Immerhin wirds ja fuer jede Abfrage neu berechnet und nicht nur einmal beim Export/Import. Goos

Fein, ich wusste nicht, dass es dafuer nen Standard gibt. Dankeschoen fuer die Info Goos

Nuja, der Fall mit der Berechnung haengt aber dann auch stark von der Selektivität deiner Suchabfrage ab Goos

Vom Fall 3 wuerd ich grundsaetzlich schonmal abraten, es sei denn die Dauer ist immer nur ein zusaetzliches Kriterium und wird dann ueber einen sehr beschraenkten Zeitraum ausgewertet (nicht mehr als ein paar hundert Datensaetze). Da sowas in der Regel aber nicht garantiert werden kann, solltest dich zwischen Loesung 1 und 2 entscheiden. Prinzipiell wuerde ich zu Loesung 1 raten. Es kommt aber nun darauf an was auf dem MSSQL System sonst noch laeuft. Du nimmst damit auf jeden Fall die Last der Berechnung vom MySQL System, welches ja zur Zeit des Imports wahrscheinlich möglichst produktiv bleiben soll. Ein Index auf die "Dauer"-Spalte wuerd ich zusaetzlich zu den Indizes auf "Start" und "Ende" natuerlich als Pflicht ansehen. Goos