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.

Aber egal welches Datenbanksystem du verwendest es ist nie eine gute Idee innerhalb eine Datenbanktransaktion noch Userinteraktion zuzulassen.

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

Kannst dir mal table hints (Table Hints (Transact-SQL)) und im Speziellen ROWLOCK anschauen. Vielleicht hilft das.

Kurz gesagt : Nein !

Grund, siehe weiter unten

Egal bei welcher Datenbank wenn du anfängst Zeilen selbst mit einem Lock zu versehen musst du dir auch darüber Gedanken machen wie du sie wieder frei gibst. Was ist wenn dein Programm nach dem Lock abstürzt?

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.

An sich ist das wahrscheinlich nicht sonderlich kompliziert - zunächst wärs aber hilfreich wie genau ein Eintrag in der Spalte aussieht, dann kann man den bspw. mit Substring zerlegen.

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

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 ..........

Ich möcht dir nich zu nahe treten ....

Aber :

Kenntnisse: Java EE, XML, JSF, PHP, HTML, JavaScript, SQL, hybris, SAP, jCat, C, C++, C Sharp

Du, ich sags ganz ehrlich, nehm ich dir nicht ab. Ohne dich gesehen zu haben, mit dir geredet zu haben, mit 23, die Aufzählung, Nope, nehm ich dir nicht ab.

Für mich sieht das aus nach "das hab ich alles schonmal gesehn" aus, und ich wüsste jetzt NICHT, was du kannst. Nimm mal zumindest 1-2 Sachen in die "tiefere Kenntnisse" auf, aber einfach nur "Zeug" durch die Gegend werfen, wie C++ und SQL, ne.... sorry echt nich.

2000 Euro Anschaffung für ein Auto, ganz grob mal (Versicherung und Reparaturen) noch mal 2000 Euro pro Jahr drauflegen und du hast die Bahncard 100 2. Klasse. Die Bahncard 100 enthält das City Ticket (Nahverkehr in 120 Städten). Ist Nämberch dabei?

Alternativ: ~ 80 Euro für Monatskarte Nahverkehr und endlich mal die 10 Regalmeter Bücher durchlesen, die sich angesammelt haben. Hat für mich einen ziemlichen Reiz.

Des is arg abhängig von der Wohngegend würd ich sagen.

Auf dem Dorf kannst du mit der Bahncard 100 nix anfangen, weil keine Züge fahren, in der (Gross-)Stadt braucht man eh kein Auto.

Die Rechnung is nicht pauschal, is mein Punkt.

Hi,

Wenn aber mal was kaputt geht, da muss man Knowhow haben, und wissen, wie man ein Backup zurückspielt und so wenig Datenverlust hat wie nur möglich verursacht. Sofern man denn eins hat. Soll ja auch Firmen geben die verzichten aus sowas. Wie auch immer, das scheint so das Schicksal der DBAs zu sein.

nicht.

Offen gesagt, kann ich euch zwei nich wirklich verstehen. Ich bin "halber" DBA, komm aber aus der Developer Ecke. Wenn ich ne Datenbank seh, dann weis ich nich wo ich anfangen, und wo ich aufhören soll.

Ne Backupstragegie und nen Disaster Recovery Plan is das bare minimum.

Hot-Standby, Skalierbarkeit, Datenschutz, Security, >Performance Optimierung<, wie bekommt ihr das hin das euch langweilig ist ?

Nur nen Server Aufsetzen und die Software installieren (und ab und zu nen Backup einspielen) ist langweilig... aber das is dann auch noch nich das Ende der Fahnenstange ?

Gruß

Sven

ich hätts vermutlich per

 CASE WHEN left(name,1) = ',' THEN right(name, len(name) -1) ELSE name END 

gemacht...

Du kannst auch hingehn, dir ne CLR schreiben und dir Regular Expressions aus dem .Net Framework implementieren, ist was recht praktisches und managed Code ... das führt jetzt aber wohl zu weit.

prinzipell sollte das aber eine recht lösbare Aufgabe sein

Ps.: Mich würd auch interessieren was an Goos seiner Lösung falsch ist. Ich seh da auch nix ...

Das solltest du nicht in physikalischer Nähe zu einem C# Entwickler sagen

Als VB.NET Entwickler, sage ich, dass ein C# Entwickler besser nicht hochnäsig die Nase rümpft in physikalischer Nähe......

Bei mir steht jetzt auch ein AG wechsel an :

Alter: 28

Wohnort: Mannheim (Umzug nach Bern ist gard in arbeit)

letzter Ausbildungsabschluss (als was und wann): FIAE 2010

Berufserfahrung: 2 Jahre

Vorbildung: Abitur, abgebrochenes Informatik Studium

Zertifikate : MCTS SQL Server2008 Administration & Maintainance, MCTIP (+ das entsprechende MCTS als prerequisite) SQL 2008 Developer

Arbeitsort: Bern

Tarif: -

Grösse der Firma: ca. 150 MA

Branche der Firma: Softwareentwicklung von Kassensystemen incl. Warenwirtschaft

Arbeitsstunden pro Woche laut Vertrag: 40

Arbeitsstunden pro Woche real: 40 (Gleitzeitkonto & Überstundenkonto)

Gesamtjahresbrutto: 90.000 CHF

Anzahl der Monatsgehälter: 12

Anzahl der Urlaubstage: 20

Sonder- / Sozialleistungen: Evtl. Boni am Ende des Jahres, verkünstigt Fitnesscenter & Apotheke um die Ecke

Variabler Anteil am Gehalt: -

Tätigkeiten: SQL Entwicklung (ca 50:50) und pflege / entwicklung eines Administrativen ASP.NET Basierten Administrativen Frontends

SET @product_id = ?

SET @new_price = ?



UPDATE products 

SET products_price = @new_price 

WHERE products_id = @product_id;


UPDATE gp

SET personal_offer = CASE 

							WHEN quantity >= 5 THEN prod.product_price * 0.85

							WHEN quantity >= 3 THEN prod.product_price * 0.9

							ELSE quantity THEN prod.product_price

					END

FROM grad_price as gp INNER JOIN products prod ON gp.products_id =prod.products_id					

WHERE prod.products_id = @product_id;

Ich habs nie getestet .... aber sollte meinem Dafürhalten nach funktionieren

Die Überstunden Klausel dürfte in dem Fall unwirksam sein.

Älteres BAG Urteil :

Pauschalabgeltung verstößt gegen Transparenzgebot » Rechtsprechung » arbeitsrecht.de

Aktuelleres BAG Urteil :

Bundesarbeitsgericht: Überstunden müssen bezahlt werden - Wirtschaft | STERN.DE

Urteilsbegründung

Soweit ich das lese dürfte der Fall recht klar sein. Nen Anwalt Fragen ist im Zweifel aber vermutlich auch nicht verkehrt.

Gruß

Sven

bah .... geh nie mit nem schotten in nem irish pub einen sauffe, und zahl den abend, während der schotte ****en is ....

Anyway ....

Ich würd dir raten, wenn du Excel VBA "musst", setz nen verweis auf die mscore.lib

Das gibt dir in Excel VBA das recht komplette .Net Framework.

Hashtables, Dictionarys was das Herz begehrt.....

bei 1.5 mio rows record sets, würd ich mich nicht freiwillig auf excel vba begrenzen wollen muss ich sagen. (Ich geb dem ne 50:50, dass Excel mit ner out of memory aussteigt.....)

Gruß

Sven

Hi Carsten,

ich würde an deiner Stelle, die Verbindung über ein ODBC Connection Object erstellen, und die Daten dann erstmal in ein das ein Recordset Object schreiben.

Das kannst du dann Durchloopen und row für row dann entweder in die Excel Datei, oder was vermutlich sinnvoller wäre, gleich in eine sauber formatierte CSV schreiben.

Bei Bedarf kann ich dir n bissl Quellcode raussuchen / schreiben als Beispiel.

Du kannst aber eigentlich Excel dann auch gleich weglassen, und dir das ganze in C# oder VB.NET schreiben, da haste dann weniger Probleme mit.

Gruß

Sven