SQL Server Synchronisation

Re(15): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 16:24:12 GMT

Schönes Beispiel

Das war zwar mal schnell aus den Fingern gesogen - aber ähnliche findest echt oft in der Praxis... Und eben auch in Lehrbüchern, was schon giftig ist...

*pfeif* .... Spass beiseite. Manchmal muss man es machen, weil es anders keinen Sinn ergibt und semantisch einfach nicht korrekt wäre (ich kann nicht einfach null zurückliefern, wenn man eigentlich ein Objekt mit bestimmten Eigenschaften erwartet, genausowenig Sinn macht es ein leeres Objekt zurückzuliefern.)

Klar kann Exception-Werfen Sinn machen... Und ich behaupte ja auch nicht, daß ein Programmierer immer faul war, wenn er ein throws.. schreibt. Ich behaupte aber doch, daß öfters mal einer faul war .

Wobei "Ich kann nicht null zurückliefern"... Was spricht dagegen ?
Fast alle C-Funktionen liefern NULL oder -1 im Fehlerfall... Das ist ein "gut eingelebtes" Konzept....

Für den Aufrufer wäre es sogar gleich...
Bei Dir (throws...) müßte er schreiben


try { MeinObjekt meinObjekt = MeineObjektFactory.holEins(); meinObjekt.machwas(); } catch (....)

Denselben try/catch-Block hättest auch, wenn "holEins()" statt eine Exception zu thrown einfach null zurückliefert... Denn ab "machWas()" fliegt die Exception und Du bist genauso im catch().

Wenn aber null zurückgeliefert wird, kannst auch "if (...holEins() != null) {...}" durchführen...

Exceptions werfen kann aber durchaus dann Sinn machen, wenn es beispielsweise 3 Gründe geben kann, warum eine Funktion nicht so tut wie der Aufrufer wohl wollte - und du ihm das mitteilen willst (zB durch eigene Exceptionklassen). Dann wird's schon gerne mal sehr brauchbar... Und das deckt sich so mit meiner These "Exceptions sind super für Ausnahmesituationen".... Beispielsweise einr "throw new AusserhalbDerDienstzeitNichtErlaubtException();"... - wenn dein "Ich kann nicht einfach NULL zurückliefern" so gemeint war - sind wir nahe beieinander.

Andererseits war ich aber auch mal bei einem Projekterl, wo /wirklich viele/ eigene Exceptionklassen definiert wurden... Mit dem logischen Erfolg, daß kein Aufrufer sich je antat, nach der Art der Exception zu unterscheiden und wohl 90% des Handlings a la "try { machWas(); } catch (Exception ex) { SagUser(ex.messageText); }" aussahen

Re(9): SQL Server Synchronisation

Ardjan — Wed, 07 Mar 2007 15:01:39 GMT

Zeichenverkettung würde sicher gehen, aber dann kann der Wert nicht mehr automatisch im Applikation weiterverarbeitet werden, bzw erst nach kompliziertes parsen.

Gibt's im SQL-Server kein CREATE VIEW .... ?

Natürlich, aber ich weiß nicht wie ich dann aus der App mit "Select * From View Where Arg = 1100" arbeiten kann...

Re(15): SQL Server Synchronisation

Somnatic — Wed, 07 Mar 2007 14:48:28 GMT

Mach dir nichts draus ... kommt von ganz allein.

Re(14): SQL Server Synchronisation

Somnatic — Wed, 07 Mar 2007 14:48:00 GMT

Schönes Beispiel

Allerdings muss ich dazu sagen, dass ich gerne konkrete Fehler abfange, nicht generell mal die Mutter aller Exceptions Damit könnte sich dieses Problem evtl. umschiffen lassen. Wobei die Problematik natürlich bleibt, da hast du schon Recht. Dazu muss ich sagen, dass dies in Java irgendwie besser gelöst ist als in .net.

Noch schlimmer sind oftmals Funktionen, wo es sich der Programmierer einfach
machte - und ein throws in der Deklaration angab

*pfeif* .... Spass beiseite. Manchmal muss man es machen, weil es anders keinen Sinn ergibt und semantisch einfach nicht korrekt wäre (ich kann nicht einfach null zurückliefern, wenn man eigentlich ein Objekt mit bestimmten Eigenschaften erwartet, genausowenig Sinn macht es ein leeres Objekt zurückzuliefern.) Ab und an muss eine Exception weitergegeben werden. Wobei ich dann jedoch dafür plädiere, dass diese Exception genau das Problem umschreibt, sodass das Suchen in der "fremden" Klasse nicht notwendig ist.

Ich will nicht über try/catch herziehen - aber IMHO(!) sollte man mit
try/catch sehr sparsam umgehen... Und insbesondere auf throws weitestgehend
verzichten...

Was das anbelangt gehen wir konform

Re(8): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 14:00:41 GMT

Ich habe es mit COALESCE() versucht, und das hat auch prächtig funktioniert. Dann ist aber der Frage gekommen ob ich den Ort und Gemeinde auch zurückgeben kann, und das geht mit COALESCE() nicht. COALESCE(x,y,z) liefert halt der erste Wert zurück der nicht NULL ist, kann also keine zwei Werte zurückgeben...

Nun ja, Du könntest ja so ungefähr


SELECT COALESCE ( ( SELECT Route || "-" || Gemeinde FROM qry_PLZ_Route WHERE plz = 1100 ) , -1 ) AS Route

konstruieren - also ein Trennzeichen wie "-" einführen - solange Du nicht weiter joinen mußt...

Und Query am Server speichern ?
Gibt's im SQL-Server kein CREATE VIEW .... ?

Re(7): SQL Server Synchronisation

Ardjan — Wed, 07 Mar 2007 13:54:33 GMT

Ich habe es mit COALESCE() versucht, und das hat auch prächtig funktioniert. Dann ist aber der Frage gekommen ob ich den Ort und Gemeinde auch zurückgeben kann, und das geht mit COALESCE() nicht. COALESCE(x,y,z) liefert halt der erste Wert zurück der nicht NULL ist, kann also keine zwei Werte zurückgeben...

Jetzt habe ich es mit deine Methode gemacht, und das funktioniert. Jedenfalls im Query-Analyzer. Nur noch schauen wie ich das als Query im Server abspeichern kann, sodas der Applikation nur 'SELECT * FROM qry_PLZ WHERE PLZ = 1100' zu schicken braucht. Ich weiß nicht ob der App auch komplette Queries absetzen kann...

Re(3): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 13:54:20 GMT

http://msdn2.microsoft.com/de-de/library/ms146892.aspx
?

Re(15): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 13:34:46 GMT

Sorry...

Vielleicht ein anderes Beispiel:
Angenommen, du nimmst guten, alten C-Code (der nun freilich als unakzeptabler legacy-Prozedural-Code bezeichnet wird) - dann hast du oft Konstrukte drin (wieder Pseudocode) wie


Spieler * machwas(char *name, ...) 
{
    buffer *b, *c;
    if (!(b = malloc(100)) {        // 100 Bytes f. b anfordern
        schreib_fehler("Out of Memory");
         return NULL;
    }
    if (!machWasAnderes(name)) {
        free(b);   // Bytes von b wieder freigeben
         schreib_fehler("was anderes klappte nicht");
         return NULL;
    }
   ....
   return b;           // b zurückgeben.
}

Vorteil:
Genau dort, wo ein Fehler passiert (das sind die "!"-Konstrukte) passiert die Fehlerbehandlung. Dir kann nichts durchrutschen, ....

Nachteil:
Wenn man auf das "free(b)" vergißt, hast du ein MemoryLeak geschaffen... Was ja öfters mal passierte

Lösungsansatz:
try { Mach so Einiges - fordere auch Ressourcen an, ... } catch { Reagiere auf Fehler } finally { gib alle Ressourcen wieder frei }

Klingt an sich ja absolut sinnvoll - und drum haben try/catch-Blöcke durchaus ihre Berechtigung.

Das Problem ist dabei - aus meiner Sicht(!) - daß die Fehlerbehandlung nicht gleich dort stattfindet, wo der Fehler passiert - sondern zeitlich versetzt. Dadurch kann Dir meiner Meinung nach oft auch leichter was durchrutschen als vorher...

So war auch mein Spielerbeispiel zu sehen:
Da waren 3 Schritte drin:
1.) Lege einen Spieler an
2.) Ordne ihn einem Team zu
3.) Setze seine Punkte auf 0
4.) Liefere den Spieler zurück

-- Wenn was nicht klappt - liefere Null zurück. (Das Setzen des Spielers auf NULL läßt seine Referenz verschwinden, wenn keine Referenz mehr existiert, wird er (irgendwann) wirklich gelöscht... Daher sieht der Code gut aus. (Java-Beispiel, AFAIK ist es in C# ähnlich.)

Wenn Du über so einen Code stolperst, mußt Du Dir /immer/ für jede Zeile des try-Blocks überlegen, ob das paßt.
Du beginnst also:
Wenn (1) nicht funktioniert - Dann wurde eh kein Spieler angelegt, wir liefern NULL zurück - paßt.
Wenn (2) nicht funktioniert - Dann wurde er keinem Team zugeordnet, wir setzen eh im catch() den Pointer auf NULL, dadurch wird die einzige Referenz eliminiert - paßt.
Wenn (3) nicht funktioniert... Dann wurde der Spieler aber schon einem Team in (2) zugeordnet - dann hat das Team eine Referenz, die es wohl nicht haben sollte. Dadurch wird der Speicher nicht freigegeben - und das Team hat einen ungültigen Spieler drinnen... Wenn es /irgendwann/ beim Schreiben dein Programm aufstellt, weil Du eine Spielerliste der Teams ausgeben willst... Findest Du dann auf die schnelle den Fehler, der hier passierte ??? Also ich brauche meistens laaange

Der Fehler war in diesem Beispiel die Reihenfolge...
1.) Lege einen Spieler an
2.) Setze seine Punkte auf 0
3.) Ordne ihn einem Team zu
wäre richtig gewesen

Meiner Meinung nach sind try/catch-Blöcke oftmals weit schwieriger zu debuggen... Weil Du, wenn du gerade im catch()-Block bist Dir Fehler überlegen mußt, die ganz wo anders haben passieren können...

Drum setze ich try/catch zwar schon gerne ein - aber eben nur sparsam.

Re(14): SQL Server Synchronisation

Cereal_Poster — Wed, 07 Mar 2007 13:09:18 GMT

cool...und wieder bin ich beim Status "Ich versteh nur Bahnhof" angekommen
(was aber nicht an deinem Beispiel, sondern an meiner absoluten Unwissenheit liegt)

Re(10): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 13:04:11 GMT

ahhh...jetzt hab ichs....ist aber wirklich eine sehr umständliche Lösung, oder

Hehe... Genau drum schrieb ich ja "War eh eine dumme Lösung---"

Wobei ich obiges zu meiner Schande oft in Access verwendete...
NVL gab's in Access97 nicht (entspricht COALESCE), und COALESCE... daran dachte ich nicht (k.A., ob's das gab).

Re(13): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 13:02:09 GMT

Hätte ich ein bißchen anders gesehen....

Grundsätzlich teile ich deine Beschreibung des semantischen Unterschieds...

Für "normale" Behandlung ist if/then/... super...
Für "anormale" Ereignisse eher try/catch...

try/catch-Beispiel, das IMHO Sinn macht:
try { a=b/c ; b = d/a ; f=a/(b*c) ; h=2*3/f^g } catch (DivisionByZeroException ex) { //Behandle Division durch 0 }

Natürlich könnte man das alles auch durch if/then-Lösen... Unter Einsatz von Hilfsvariablen für den Nenner, die jede vorab einzeln auf 0 überprüft werden... Dann wird's aber unnötig lang.

Problematisch ist an Exceptions IMHO die Fehlersuche. Beispiel in Pseudocode:


static function neuerSpieler(String name, Team team) returns Spieler
{
  // legt einen Spieler mit Namen name an und ordnet ihn einem Team zu.
  // liefert im Fehlerfalle NULL als Spieler zurück.
var spieler = null;
try {
   Spieler spieler=new Spieler(name);
   team.add(spieler);
   spieler.setpoints(0);
} catch (Exception ex) {
  spieler = null;
}
return spieler
}

Dieses Beispiel (leider oft ähnliches auch in Lehrbüchern gefunden) zeigt die Probleme bei Exceptionhandling - alles IMHO

Auf den ersten Blick sieht's nicht ganz schlimm aus...

Fürchterlich wirds aber, wenn spieler.setpoints() eine Exception werfen kann...
Denn dann hätten wir einen angelegten Spieler im Team - er würde nur nicht zurückgeliefert. Im besten Falle "nur" ein Memoryleak... Schlimm aber, wenn man später über die Teams iteriert und eine Mitgliederliste baut... Denn dann gibt's eine Referenz auf einen Spieler (wg. team.add() ), die aber zu keinem "gültigen" Spieler führt (zumindest zu einem, bei dem - warum auch immer - setpoints() nicht klappte...

Noch schlimmer sind oftmals Funktionen, wo es sich der Programmierer einfach machte - und ein throws in der Deklaration angab.... Wenn du so eine Funktion verwendest, muß man sich gelegentlich für jede einzelne Zeile der Funktion ansehen, wie dein catch() aussehen müßte...

Ich will nicht über try/catch herziehen - aber IMHO(!) sollte man mit try/catch sehr sparsam umgehen... Und insbesondere auf throws weitestgehend verzichten...

Und es eigentlich nur für Ausnahmefehler verwenden, wobei ein if-then-else oft den Vorteil hat, daß der Fehler genau da behandelt wird, wo er passiert - und dadurch der Code oft (natürlich nicht immer) bei weitem lesbarer wird.

Re(2): SQL Server Synchronisation

MidiFan — Wed, 07 Mar 2007 11:48:21 GMT

Wegen der Datensicherheit wird es ja nicht sein - denn dann müßten immer beide
online sein.
Es wird also -vermutlich- darum gehen, daß er seine Datensätze
sehen/bearbeiten kann, auch wenn er offline ist...
(denn sonst würde man ja nur eine Datenbank am VerkaufsPC fahren).

stimmt. backup wird warscheinlich noch extra gemacht werden sobald sich das notebook verbindet.

Du hattest eine "Masterdatenbank" - und am Lappy (zB als Kundenbetreuer) ein
Replikat, daß du ein- und auschecken konntest... Das war beliebt für
Außendienstmitarbeiter, die am Lappy ihre Kundendatenbank, ... mitnahmen - und
beim einchecken ins Firmenlan ihre Daten auf den Master zurückspielten...

es soll extern eigentlich keine daten hinzukommen, sondern nur diverse Auswertungen bei bedarf unterwegs gemacht werden. wenn das notebook im lan hängt sollen natürlich neue daten hinzugefügt werden können. deshalb finde ich die idee das sich das notebook zum server verbindet nicht schlecht.

Also so:
bei nw Verbindung:
neue daten werde über das netzwerk direkt auf dem server hinzugefügt. ist das beendet wird eine replikation auf das Notebook gemacht welches dann alle daten bis zum replikationszeitpunkt hat.

ohne nw Verbindung:
es können keine daten hinzugefügt werden, sondern nur berichte von den vorhandenen Daten erstellt werden.

Re(12): SQL Server Synchronisation

Somnatic — Wed, 07 Mar 2007 10:43:53 GMT

Ein

if (var = false) { ... }

ist etwas was man unterlassen sollte Was du dir anschauen kannst sind Patterns. Da gehts dann drum, wie bringe ich einen Vorgang in der realen Welt möglichst gut in mein Tool. Ein Beispiel dafür wäre das Observer Pattern. Natürlich gibts da noch einen ganzen Haufen mehr. Auf der anderen Seite stehen dann natürlich die Coding Conventions, aber die sind meist Team - Abhängig.

ABER: Ich bin da auch kein Profi. Ich studier das nicht, ich mach das nicht beruflich, mich interessierts nur, aber übermäßig viel Zeit widme ich dem nicht. Daher: Was ich sage muss nicht unbedingt der Realität entsprechen

Re(9): SQL Server Synchronisation

Cereal_Poster — Wed, 07 Mar 2007 10:35:35 GMT

ahhh...jetzt hab ichs....ist aber wirklich eine sehr umständliche Lösung, oder?

Re(11): SQL Server Synchronisation

Cereal_Poster — Wed, 07 Mar 2007 10:34:00 GMT

Naja...das ist eben etwas das ich beim Programmieren nicht weiß: Gibt es sowas wie gewisse Sachen die man einfach nicht macht? Oder gibt es quasi einen "Guide zum schönen Programmieren". Gibt es da so Vorgaben, wie man vorgehen soll bei solchen Sachen?

Re(8): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 10:32:50 GMT

War eh eine dumme Lösung---
Ardjans war weit besser: http://forum.geizhals.at/t482781,3997692.html#3997692

Meine Lösung hätte wie folgt funktioniert:
1.) Datensatzzeile zurückliefern... Also wahlweise 0 oder 1 Row.
2.) Unten dann eine "Nicht gefunden"-Zeile dranhängen - Also fix 1 Row.

Du hast nachher 1 oder 2 Rows als Antwort...
Und durch das TOP1 sagst "Ich will nur die erste Zeile"

Re(10): SQL Server Synchronisation

Somnatic — Wed, 07 Mar 2007 10:28:27 GMT

Dann ist der beste Weg sowieso einfach eine Stored Procedure mit einem if
drinnen, oder?

Den besten Weg gibts doch nie. Der eine würds so machen, der andere so. Richtig ist beides Außerdem würd ich mir nie anmaßen zu sagen: Das ist richtig, das ist falsch. Ich hätts halt anders gemacht, aber solang es halbwegs logisch erscheint - warum nicht Alle Wege führen nach Rom

Re(7): SQL Server Synchronisation

Cereal_Poster — Wed, 07 Mar 2007 10:27:51 GMT

den kapier ich jetzt aber nicht. Was bringt da ein UNION?

Re(9): SQL Server Synchronisation

Cereal_Poster — Wed, 07 Mar 2007 10:26:31 GMT

Semantik

Siehst, und davon hab ich eben (noch?) Nüsse Ahnung

dann brauchst aber erst Recht wieder ein if

Dann ist der beste Weg sowieso einfach eine Stored Procedure mit einem if drinnen, oder?
Brauchst ja nur was in der Art:
IF SELECT IRGENDWAS is NULL
PRINT 'Keine Daten gefunden'
ELSE
......
(das ist jetzt natürlich vollkommen syntaktisch unausgereift).

btw: Du gerätst immer mehr in die Materie

Ja, und das macht mir Angst, weil es mir noch dazu wirklich Spass macht

Re(11): SQL Server Synchronisation

Ardjan — Wed, 07 Mar 2007 10:20:23 GMT

Ja, weil sie werden trotzdem vom gleichen Niederlassing aus betreut. Es geht um die Zuordnung PLZ - Niederlassung...

Re(8): SQL Server Synchronisation

Somnatic — Wed, 07 Mar 2007 10:16:29 GMT

Semantik

try catch verwende ich zur Fehlerbehandlung. Wenn ich den Status "nicht gefunden" als Fehler interpretieren kann, dann ists angebracht. Wenn ich das jedoch nicht als "Fehler" ansehe, sondern als gewollte Ausgabe, würde ich eher ein if/else verwenden. Ich glaube auch nicht dass eine Exception geworfen wird, sofern das Resultset empty ist. Aber gut, im Notfall könnte man die ja selber generieren, dann brauchst aber erst Recht wieder ein if

Inwiefern ein Try/Catch in TSQL existiert weiss ich jetzt nicht, wie gesagt: /me ist kompletter DB Noob Natürlich gibts zur Lösung eines Problems auch andere Möglichkeiten

btw: Du gerätst immer mehr in die Materie

Re: SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 10:11:36 GMT

Macht da eine Synchronisation Sinn ?

Wegen der Datensicherheit wird es ja nicht sein - denn dann müßten immer beide online sein.
Es wird also -vermutlich- darum gehen, daß er seine Datensätze sehen/bearbeiten kann, auch wenn er offline ist...
(denn sonst würde man ja nur eine Datenbank am VerkaufsPC fahren).

Ich kenne das mal nur von Access, aber da gab's doch genau für diesen Fall die Replikation (also nicht Synchronisation), die da hinziehlte...

Du hattest eine "Masterdatenbank" - und am Lappy (zB als Kundenbetreuer) ein Replikat, daß du ein- und auschecken konntest... Das war beliebt für Außendienstmitarbeiter, die am Lappy ihre Kundendatenbank, ... mitnahmen - und beim einchecken ins Firmenlan ihre Daten auf den Master zurückspielten...

Unter Synchronisation verstehe ich mehr 2-Phase-Commit und ähnliches - was du hier ja wohl nicht brauchst..
Oder ist das beim SQL-Server komplett anders ? (Wahrscheinlich).
Wenn ja, könnest ja am Lappy ACCESS verwenden - denn das Replikat klappt afaik auch dann fein, wenn der Master ein SQL-Server ist (anders wäre es in Firmen ja sinnlos)...

Re(10): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 10:05:56 GMT

Hmmm... Sicher besser

Wobei...
Ist es in deinem Fall völlig egal, wenn zwei Orte, die einige Kilometer Abstand haben, dieselbe PLZ haben (da gibt's nicht so wenige )

Re(7): SQL Server Synchronisation

Ardjan — Wed, 07 Mar 2007 10:04:26 GMT

Ich habe es schon mi http://forum.geizhals.at/t482781,3997692.html#3997692 gelöst...

Aber vielleicht hätte es in deine Richtung auch geklappt, stimmt.

Re(6): SQL Server Synchronisation

googleDork — Wed, 07 Mar 2007 10:00:18 GMT

Hmmm... Kenne mich leider in SQL nicht aus...

Vorschlag a la


SELECT TOP1 NAME FROM (
         SELECT name, 1 AS REIHENFOLGE FROM ort where plz = &a
         UNION
         SELECT "NICHT EXISTENT" FROM dual, 2 AS REIHENFOLGE
) as foo
ORDER BY REIHENFOLGE

klappt nicht?

Re(7): SQL Server Synchronisation

Cereal_Poster — Wed, 07 Mar 2007 09:37:10 GMT

Das dachte ich mir nämlich auch. Als SQL n00b meine ich, er könnte das doch auch mit einem TRY-CATCH machen in einer Stored Procedure? Also im TRY erstmal ausprobieren ob ein Datensatz da ist. Im Catch dann eine Variable setzen und danach mit einer IF-ELSE je nach Variablenwert das eigentliche Select durchführen (und eben das Ergebnis ausgeben) oder wenn die Variable sagt "gibt es nicht", dann halt ein "Gibt es nicht" ausgeben...
Oder denk ich da zu kompliziert?
Oder brauch ich beim TRY CATCH das IF-ELSE gar nimmer, weil es im Erfolgsfall sowieso das die Abfrage zurückgibt und im CATCH nur das Fehlerhandling gemacht wird? Dann kann ich mir das IF-ELSE gleich sparen...

Re(9): SQL Server Synchronisation

Ardjan — Wed, 07 Mar 2007 09:08:45 GMT

Ich habe der Lösung schon gefunden...

SELECT COALESCE ( ( SELECT Route FROM qry_PLZ_Route WHERE plz = 1100 ) , -1 ) AS Route

liefert der richtigen Route wenn der PLZ exisiert, sonst kommt '-1' zurück. COALESCE() ist ähnlich wie CASE, aber in single line zu verwenden. Diese Abfrage kann ich ruhigen Gewissen im Application stellen, ohne das meine 'Geheimnisse' öffentlich werden...

Re(8): SQL Server Synchronisation

Somnatic — Tue, 06 Mar 2007 21:36:45 GMT

Naja, wenn ich mir zum Beispiel sowas ansehen:

http://www.databasejournal.com/features/mssql/article.php/3087431


if (select count(*) from Pubs.dbo.Authors
	        where au_lname like '[A-D]%') > 0 
	   print 'Found A-D Authors'

Dann kannst ja ein if select count(*) auf deine DB ausführen. Wenn er was findet, dann gibst das eben aus (evtl. in einer 2ten abfrage). Ansonsten gibst eben was anderes aus. Ich weiss nur leider nicht
a) Wie man da die Datasets definiert (aber das liesse sich herausbekommen und dazu müsste man wissen, was genau geliefert werden soll, wenn er nichts findet)
b) wie das performet (das müsste man evtl. mal testen).

Re(7): SQL Server Synchronisation

Ardjan — Tue, 06 Mar 2007 21:31:36 GMT

Auskennen: mit aufsetzen, und standard-Abfragen (SQLs mit ein handvoll Joins, Zeichenverketten usw) kriege ich auch zusammen. Aber dieses Problem ist bisher etwas zu groß für mich. Und niemand hat effektiv helfen können...

Re(6): SQL Server Synchronisation

Somnatic — Tue, 06 Mar 2007 21:01:02 GMT

Ich kenn mich mit Datenbanken leider viel zu wenig aus ...

Aber wennst eh mit TSQL arbeitest, was hindert dich daran in einer Stored Procedure irgendwo ein IF einzubauen. Kann man da dann das Ausgabe - Dataset nicht verändern?

Re(6): SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 20:54:19 GMT

Genau - wozu einfach - wennst kompliziert auch geht...

Re(5): SQL Server Synchronisation

MidiFan — Tue, 06 Mar 2007 20:51:04 GMT

Trotzdem wird das ein Problem geben - und mit der Express Edition sowieso...

das werd ich rausfinden

Re(8): SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 20:47:52 GMT

Nicht da wo ich jetzt bin...aber ich kann Dir morgen ein paar Snippets pasten...aber das solltest Dir anschauen...das ist IMHO mit das Mächtigste für solche Sachen...

Re(7): SQL Server Synchronisation

Ardjan — Tue, 06 Mar 2007 20:46:12 GMT

Hast du etwas (Pseudo)Code? Ich stehe derzeit an, ich gebe es ehrlich zu...

Re(6): SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 20:44:20 GMT

Ich hab schon gesehen, daß Du das gefragt hast...

Kannst nur über eine Inbound-Function lösen...wennst es nicht direkt auswerten kannst...

Re(5): SQL Server Synchronisation

Ardjan — Tue, 06 Mar 2007 20:39:03 GMT

MIR brauchst über SQL Server nichts erzählen

Gut, dann hätte ich eine Frage, die ich selber leider nicht hinkriege:

Gegeben eine PLZ-Tabelle, wo etwa 2300 Zeilen (PLZ von ganz Ö) drinnen stehen mit der Gemeinde. Wenn jetzt ein PLZ angegeben wird, soll der richtige Gemeinde zurückkommen. Sowas macht man mit links, ich weiß. Aber wenn eine nicht-existierende PLZ angegeben wird (zB 4711), soll nicht 'nichts' zurückkommen, sondern 'existiert nicht'. Das ganze aber als Query von draussen über ODBC abrufbar...

Wennst das schaffst, bist du gut...

(oh ja, meine Zwischenlösung das ich auf die schnelle eine PLZ-Tabelle mit 9000 Zeilen (1000-9999) angelegt habe (scripting in Transact-SQL macht spaß), zählt nicht. Was ähnliches muß ich auch für Vertragsnummern machen... )

Re(4): SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 20:33:16 GMT

MIR brauchst über SQL Server nichts erzählen...

Trotzdem wird das ein Problem geben - und mit der Express Edition sowieso...

Re(3): SQL Server Synchronisation

Ardjan — Tue, 06 Mar 2007 20:32:16 GMT

Mit Transactional Replication (http://msdn2.microsoft.com/en-us/library/aa237164(SQL.80 ).aspx) auch kein Problem. Das kann man so einstellen das erst wenn der Transaktion in beide TransaktionLogs geschrieben wurde, committed wird. Dann gibt es kaum latency.

Ist in sein Fall nicht notwendig, klar, aber möglich wäre es. Ein Beispiel ist zB der Replikation zwischen Firmen-DB und Web-DB, wobei durch (horizontale und vertikale) Filterung nur bestimmte Daten am Web-DB repliziert werden.

Re(4): SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 20:27:36 GMT

Wie OFT hab ich das KANN NICHT PASSIEREN schon gehört...

Und nein - replizieren ist nur doppelte Arbeit...

Re(3): SQL Server Synchronisation

MidiFan — Tue, 06 Mar 2007 20:26:29 GMT

das kann nicht passieren...
das ding ist ein 1 Mann (Trafik) betrieb.
zwischen dem lager pc und dem verkaufs pc sind 5 m. aber beim verkaufs pc ist leider ein zu kleiner monitor angeschlossen und eine verkaufstastatur so das lagerverwaltung nicht wirklich komfortabel ist.

Re(2): SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 20:21:40 GMT

Du übersiehst noch was ganz Anderes...

Der VERKAUF verkauft vielleicht etwas...was im LAGER schon gar nicht mehr da ist...bzw. umgekehrt...

Re: SQL Server Synchronisation

Ardjan — Tue, 06 Mar 2007 20:19:31 GMT

Es geht schon. Man kann den SQL-Server in 7 Stufen miteinander replizieren lassen. Von gleichzeitig im Transaktionslog schreiben und erst Commiten wenn alles geschrieben ist bis zu Replikation per Floppy... Ein Anlaufpunkt findet sich hier: http://www.microsoft.com/technet/prodtechnol/sql/2000/technologies/replictn.mspx

Aber wenn die zwei Rechner eh im gleichen Gebäude durch ein schnelles LAN verbunden sind, würde ich mir die Mühe nicht machen... Als Datensicherheit würde ich aber eine externe HD anhängen und ein Wartungsplan anlegen welche die DB regelmäßig sichert.

Re(3): SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 17:15:19 GMT

Korrekt...

Re(2): SQL Server Synchronisation

MidiFan — Tue, 06 Mar 2007 17:14:56 GMT

also nur eine Datenbank.. und wenn das lager verwaltet werden soll vom lager pc auf kassa pc zugreifen.

Re: SQL Server Synchronisation

Pervasive — Tue, 06 Mar 2007 17:13:20 GMT

Selbstmord mit Anlauf...

Wenn - SQL Server am Verkaufs PC laufen lassen und den Lager PC wenn eingeschalten dort andocken...

SQL Server Synchronisation

MidiFan — Tue, 06 Mar 2007 16:57:38 GMT

es geht um 2 Pc's

Verkaufs Pc:
der Verkaufs pc steht an der Kasse, auf ihm läuft ein SQL Express Server
hier wird nur ware verkauft.

Lager Pc:
der Lager pc wird dazu genutzt um das Lager zu verwalten, Inventur, änderungen an Produkten, Preise etc. auf ihm läuft ebenfalls ein SQL Express Server.

die beiden pc's sind per lan verbunden, wobei aber der lager pc nicht immer eingeschalten/anwesend (notebook) sein wird. wie kann ich eine bidirektionale Datenupgleich machen?

SQL Server Synchronisation

MidiFan — Tue, 06 Mar 2007 16:57:38 GMT