streffin

>Gerade der MS SQL Server bietet z.B. auch noch andere Locks an z.B. Application Locks. Davon abgesehn das ich noch nie jemanden getroffen hab der das wirklich benutzen würde, und es in freier Wildbahn bisher nicht 1x sehen musste : MSDN Zitat : "Locks placed on a resource are associated with either the current transaction or the current session. Locks associated with the current transaction are released when the transaction commits or rolls back. Locks associated with the session are released when the session is logged out. When the server shuts down for any reason, all locks are released. The lock resource created by sp_getapplock is created in the current database for the session. " Preisfrage : Was passiert mit deiner Session wenn die zugehörige connection gekillt wird ? >Hinzu kommt das per default zumindest mal im MS SQL Server es kein time out für Transaktionen gibt Das wäre der Command timeout des connection Strings, und wenn ich nicht ganz stark irre, dann gabs da defaults auf server und database level. (link) Aber ja, immer noch, deine DB connection wird aus welchen Gründen auch immer geclost, dein Locking geht zum Teufel. Ergo, Db seitiges Locking ist immer noch kein brauchbares instrument um diese BUSINESS LOGIC zu implmentieren. Mal ganz davon abgesehen, dass ich als Programmierer doch durchaus nen etwas anderes Feedback von einer Function haben möchte, die mir datensätze updated, als eine SQL Exception, einen SQL Command Timeout, oder einfach gar nichts und die drehende Sanduhr für 5 Stunden..... Warum in aller Welt bist du so erpicht auf DB seitigem Locking ? Es ist Session=Connection abhängig, wie dus drehst und wendest, und schlicht und ergreifend nicht das richtige Mittel. Wir reden von Application calls, nicht von dem was du ins Managment Studia hackst. Und sorry, wer sich ne command timeout von 0 im Frontend leistet, der hats irgendwo verdiehnt. Selbst wennd den connection string von connectionstrings.com copy pastest hast de immer noch die default db settings für den timeout. da sind wir uns einig.

Unter MSSQL kannst du per XQuery auch direkt im SQL Query das XML parsen*. * Parsen im Sinne von, per XQuery kannst du die XML Strukturen navigieren, also einzelne Nodes / Attribute lesen und schreiben. Dazu kannst du wenn es nur ums speichern von Daten geht das ganze auch in ein XML Field schreiben. In neueren Versionen des SQL Servers kannst du eine XML Column sogar indizieren. Wenns um mehr als das doofe speichern von XML Daten geht, würd ich das aber normalisieren und sauber weg schreiben.

Sorry, aber nein. Wir reden hier von MS SQL Server 2008 R2, nicht von einem abstrakten DBMS, also dürfen wir hier schon konkret auf die Eigenenheiten eingehen. Wenn du die connection terminierst die aktuell noch eine Transaktion oder einen Lock offen hält, dann wird die Transaktion zurückgerollt, und/oder der Lock releast. D.h. dass sofern die App ob jetzt verteilt oder nicht, die Connection killt, dann ist dein Lock so oder so flöten. Db seitiges Locking ist schlicht das falsche für die Problemstellung. Eventuell kam das nicht ganz rüber, ich rede von DB internem Locking. RowLock, PageLock, TableLock. Das ist was allgemein (oder zumindest bei mir) unter Lock in einer Datenbank verstanden wird. Das kann in anderen DBMS's anders sein, aber wir reden von einem exakt benannten DBMS

Kurz gesagt : Nein ! Grund, siehe weiter unten Sorry, aber das ist ebenfalls schlicht falsch. Query A hält einen ReadLock auf Page xyz, --> alle anderen Prozesse warten bis Query A (das ist ein Prozess in der DB) den Lock wieder frei gibt. Über Isolation Level will hier keinen Aufsatz schreiben, aber wer with(no lock) oder read uncomitted benutzt, sollte entweder wissen was das bedeutet, oder es nicht verwenden. Wenn jetzt Query A / Prozess A, in einen Timeout läuft, dann wird die Transaktion zurückgerollt, der Lock releast, und alle anderen Queries / Prozesse, die darauf warten dass der Lock releast wird, laufen weiter. Das ist definitiv nichts, was aus dem Frontend gesteuert werden muss / kann. Allgemein zum Locking auf DB Ebene : Db seitige Locks sind dafür da, zu verhindern, dass Daten verändert werden, während sie gelesen oder geschrieben werden (das kann ganz hässliche Folgen haben). Db seitige Locks sind definitiv nicht dafür da, Business Logic zu implementieren, aka User A hat die Daten momentan im alleinigen Schreib Zugriff. Vergiss das in dem Zusammenhang ganz schnell, da tust du dir keinen Gefallen mit. Was ich dir raten würde in diesem Fall ist, im Frontend einen Lese und einen Schreib Zugriffsmodus zu implementieren. So kannst du einem User B im Frontend darstellen, dass er den aktuellen Datensatz nur lesen kann, weil User A gerade diesen Datensatz bearbeitet. Wenn du so etwas über Rowlocking machen würdest, dann hättest du ein Query von User A, dass den Lock hält, und ein Query von User B, dass >wartet< bis der Lock wieder frei gegeben wird. --> User A hält lock und editiert / geht was essen, User B schreibt support ticket weil es den anschein hat dass sich die Application gehängt hat. Du hast 2 Möglichkeiten um so ein Problem zu lösen : 1. Füge ein neues Feld in die entsprechende Tabelle ein, in der du per Update festhalten kannst, dass der Datensatz momentan bearbeitet wird. Ok, wären in der Regel 2 Felder, Feld 1 : UserID wer den Datensatz gerade bearbeitet, und Feld 2 das datum wann der Datensatz gesperrt wurde. Das wäre eine recht einfache zu implementierende Lösung. Hat allerdings auch einen nicht unwesentlichen Nachteil. Da du ständig rows Updatest, kannst du nicht mehr auf rowversion zurückgreifen um eventuell ein Datewarehouse zu updaten. Ich würde davon abraten falls machbar. Möglichkeit 2 : Nimm dir eine seperate tabelle, FK auf dem primary key deiner Tabelle die du "sperren" möchtest, und Felder für die informationen die du für den "Lock" wissen möchtest. Also "Wer", "Wann", evtl. "Warum" etc. Das kannst du wenn das Frontend statt direkt auf Tabellen auf Stored Procedures zugreift dann auch ohne weiteres zu einem Change Tracking ausbauen bei Bedarf. Nachteil hier wäre, dass du einen extra Join, oder NOT EXISTS (), hättest, um zu prüfen ob der Datensatz gerade gesperrt ist. Das wären die 2 Möglichkeiten die ich sehen würde. Vergiss aber das SQL interne row / page Locking GANZ schnell bei der Fragestellung. Wenn SilentDemise richtig verstehe, geht das auch in Richtung einer seperaten Tabelle in der dann die "gelockt von" information festgehalten wird.

Script 2 : set excel = Createobject("Excel.Application") die Office Interop ist notorisch schlecht darin, die Prozesse aufzuräumen. Wenn du mal nach excel.Quit suchst, wirst du seehr viel finden zu "warum funktioniert das nicht". Beispiel Ich hatte in der Vergangenheit ähnliche Probleme, (allerdings in .NET) und habe die dann auch über Marshal.FinalReleaseComObject() gelöst. Ich würd an deiner Stelle da ein kleines, .NET Progrämmchen schreiben, dem du per Command line die Parameter mitgibst, aber dann dafür auch mehr möglichkeiten hast, den Excel Prozess sauber zu töten wenn du fertig bist. Das unterdrücken von MessageBoxen in Excel ist recht heikel. Appliacation.displayAlerts = false fängt dir nur einen Teil. Wenn du z.b. einen SQL Fehler in einer DB Abfrage hast, dann bleibt dir der Prozess da trozdem hängen. Das kannst du eventuell mit onError GOTO abfangen, aber schön ist das nicht. Du Fährst besser wenn du die Daten von Aussen in das Excel Sheet einfügst. Tipp dazu : ein Range Objekt in VBA ist nichts anderes als ein 2 Dimensionales Array.

Warum Timestamp ? Für mich liest sich das als wolltest du da ein Datum, nicht einen Timestamp. Ein Timestamp ist ein 8 Byte Hex value. Das wird / wurde oft für row-versioning benutzt wie man das bei Datawarehouse und replications braucht (heute würde man da ROWVERSION benutzen, alles andere ist legacy code). Wenn es dir um ein wirkliches Datum geht, nimm lieber datetime oder datetime2. (Datetime2 ist schlicht genauer als Datetime) Damit sparst du dir viele eventuell später aufkommende Probleme.

Sting operationen sind allgemein sehr inperformant in (t)sql (allgemein sollte man auf Skalare Funktionen verzichten soweit machbar, alles was mit BEGIN anfängt und mit END aufhört ist zu 95% schlecht für die performance). Ein Datetime in einen String zu converten, dann mit substring rumspielen.... ne bitte nicht. Einfach ne, einfach nicht machen. 2 Beispiele die typensicher und "besser" sind : declare @a datetime =getdate() declare @b time declare @c datetime = convert(datetime, '2012-03-07 07:35:10') set @b = convert(time, @a) print @b print convert(date, @c) + convert(time, @a) Btw, wenns dir nur um den TIME teil des datetimes geht, du kannst auch ohne weiteres Felder in einer Tabelle anlegen, die vom Typ TIME sind. Damit hast du dann den richtigen Datentyp um das hinterher sauber auswerten zu können, OHNE in einem eventuell größeren Recordset erstmal alles zu konvertieren. soviel zu Konvertierung. Ansonsten Trigger wurde schon genannt, einfach nen inner join mit der INSERTED trigger Tabelle auf deine Zieltabelle und fertich. Gruß Sven

Passtrough oder auch Trusted Connection genannt, funktioniert nur im lokalen Netz, Die Authentifizierung findet dann über ActiveDirectory Gruppen und Usert statt. Wenn du nicht im selben lokalen Netz bist, funktioniert auch kein Passtrouth, da du ja nicht im AD angemeldet bist.

Ich würd den Vendor / Distirbutor als Fremdschlüssel anlegen, und das ganze in eine Tabelle schreiben. Ich würd mir auch nicht den Act machen, und da mehere Tabellen pflegen. Setz nen ssis Package auf für jedes Datenformat, schreibs in eine dafür vorgesehene Tabelle, mach von mir aus noch den filename und import datum in ne Spalte. Dann ists "aufgeräumt" Ob das jetzt inserts, merges, oder lösch alles und inserts sind, ist recht beiläufig imho.

Alternativ ... mach ein paar Zertifikate, und leg ein Xing Profil an. Bei mir wars ein halbes Jahr, dann hat ich über nen Headhunter nen Job in der Schweiz, ganz ohne mir was suchen zu müssen

Mhm, hast du eventuell lokal eine andere SQL Server Version installiert als auf dem ausführenden Server ? Ich hatte ein Problem, das deiner Beschreibung sehr nahe kommt mit einer lokalen MSSQL 2008 R2 version, und deinem MSSQL 2008 Server.

Mal ins Blaue geschossen.... Liegt die Datei eventuell auf einem Netzlaufwerk, das du lokal auf deiner Workstation eingebunden hast, und du gibst das Netzlaufwerk, statt dem Netzwerkpfad innerhalb des Packages an ? Ansonsten würd ich falls machbar, das ding mal unter dem UserAccount unter dem das Package läuft, direkt auf dem Server debuggen. Gruß Sven

jaja, 2 Monate da kann sich viel tun, ich zieh ende des Monats nach Bern ;D

Tabelle A: ID_Name | ID_Adresse | ... 01234 | 43435 | .... Tabelle B: Key | Value 01234 | Mustermann 43435 | Musterstraße 15 Mein Ziel ist die Tabelle Name | Adresse Mustermann | Musterstraße 15 unter der Annahme dass der key in Tabelle B unique ist, und ich nix übersehn hab : SELECT namen.value as [Name], strassen.value [strasse] FROM tabelle_b [namen] inner join tabelle_a [zuo] on namen.key = zuo.id_name inner join tabelle_b [strassen] in strassen.key = zuo.id_adresse Falls der key nicht unique ist, bist du so oder so angesch***en bei dem sagen wir "merkwürdigen" db design Gruß Sven

Davon abgesehn, dass ich mir nen Finger abbeis, bevor ich den "Layer" von bound Datasource zwischen mich und die DB bringen lass, die "ich machs jetzt ganz anders" Lösung wäre für den deutschsprachigen Teil der Welt vermutlich interesant wenn man den Thread beim googlen finden sollte ..........