Datenbanksynchronisierung bei Programmstart und -ende

also ich hab jetzt einfach das Dataset neu generiert, und bei mir gehts jetzt auch unter VS2010

wie gesagt: zunächst öffnets einfach die eingebundene DB. Wenn du aber im Projektexplorer deren Namen änderst, kommt der Dialog, der nach dem korrekten Namen der DB fragt.

Hallo Leute,
erst einmal hab Dank an alle für Ihre tatkräftige Unterstützung und die Denkanstöße!

@ Thilo: danke vielmals für die Unterstützung - hat leider nicht geklappt. Ich habe mittlerweile alles dreimal überprüft und alle möglichen Varianten ausprobiert... mir steigt das Programm definitiv immer bei dieser Aktualisierungsabfrage aus - zum Kinners kriejen. In dem Moment wo ich die Ausführungszeile, in der die Abfrage aufgerufen wird, inaktiv schalte läuft das Programm durch. Sowohl bei meinem Code als auch unter Verwendung Deines Vorschlages zur Datumsformatierung. Die Anfügeanfrage, welche auf die selbe Tabelle zugreift läuft einwadnfrei durch - da arbeite ich mit CDate(Me...) aber hier in der Änderungsabfrage streikt auch diese Variante.

@mcdt: Auch Dir hab Dank für die konstruktive Unterstützung. Deinen Einwand kann ich jedoch dahingehend entkräften, dass diese Software nicht im Aussendienst oder ähnlichem eingesetzt werden soll. Das Programm unter VB6 ist derzeit im Testbetrieb in einer Arztpraxis installiert. Alle Rechner (Arbeitsplätze) sind also auf relativ engen, bzw. begrenztem Raum aufgestellt und werden ohnehin jeden Morgen durch die Arzthelferin gestartet. Hier geht es auch lediglich darum die Möglichkeit zur Verfügung zu stellen dass das Programm voll funktionsfähig bleibt auch wenn das Netzwerk ausgefallen ist. Sollte es also wirklich mal vorkommen, dass ein neuer Patient aufgenommen werden muss wenn das Netzwerk nicht verfügbar ist könnte dieser Patient problemlos nur von der lokalen Station betreut werden bis das Netzwerk wieder verfügbar ist und alle Informationen auf die Zentral-DB gespielt wurde. Den Datenverlust bei Netzwerkausfall oder Blue Screen ist also in sofern vorgebeugt - die Daten sind ja auf der lokalen Datenbank zwischengespeichert.

@ErfinderdesRades: Dir auch nochmals Danke... ich werde mir das ganze dann bei Gelegenheit nochmals angucken. Mir stellt sich halt nur die Frage ob es da keine Probleme dann bei der Installation und Inbetriebnahme auf anderen Netzwerken und Rechnern gibt.

Hier zum besseren Verständnis einmal der komplette Block zur Übertragung geänderter Datensätze:

' Wenn geänderte Patienten <> 0 Dann upload zur Zentraldatenbank
If PatChgCount <> 0 Then
Me.UseWaitCursor = True
Me.ToolStripStatusLabel1.Text = "Übertrage geänderte Patientenstammdaten an Zentraldatenbank"

' Übetrage Tabelle PatDataChg (Lokal) an PatData (Zentral)
Me.PatDataChangedBindingSource.MoveFirst()

cmd.CommandText =
"Update PatData Set PatM = '" & Me.PatDatChg.CurrentRow.Cells(3).Value & "', " &
"PatKG = '" & Me.PatDatChg.CurrentRow.Cells(4).Value & "', " &
"WHERE PatName = '" & Me.PatDatChg.CurrentRow.Cells(0).Value & "' " &
"AND PatVName = '" & Me.PatDatChg.CurrentRow.Cells(1).Value & "' " &
"AND PatGDat = '" & Me.PatDatChg.CurrentRow.Cells(2).Value & "'"

For PCC = 1 To PatChgCount
con.Open()
cmd.ExecuteNonQuery()
con.Close()
Me.PatDataChangedBindingSource.MoveNext()
Next

Me.ToolStripStatusLabel1.Text = "Übertragung geänderte Patientenstammdaten an Zentraldatenbank beendet"
Me.UseWaitCursor = False
End If

Alle notwendigen Deklarationen sind erfolgt, DGV ist geladen und gefüllt, kann mir die Daten auch im Programm durch einfaches Einfügen einer MsgBox anzeigen lassen. In dem Moment wo ich an die rot markierte Zeile komme fliegt mir die Nummer mit Syntax-Error raus
Das DGV wird mittels For/Next-Schleife durchlaufen und übergibt dann der Reihe nach die Daten an die Zentral-DB... so zumindest in der Theorie und praktisch auch in der Routine zum Anfügen neuer Datensätze (und da ohne Fehlermeldung).

Gruß
Markus

welches Problem stellst du dir vor? Das Sample zeigt: Du kannst zur Laufzeit (korrekter: Vor dem eiglichen Start) den ConnectionString ändern.
Die Änderung persistiert in den Settings - gilt also auch beim nächsten Prog-Start.

Aber inzwischen hast du dich scheints eh von Databinding als ArchitekturPrinzip und der Verwendung von DB-Parametern abgewandt und ins totale Gewurstel begeben.

Hallo MaThoPa,

noch ein Tip zur nicht funktionierenden Abfragesyntax. Laß Dir mal im Direktfenster den zusammengebastelten Commandstring ausgeben und füge den mal per C&P direkt in Access in eine neue Abfrage als SQL-Text ein. Dann kannst Du dort ggf. erstmal einfacher mit der Formatierung des Datumsliterals herumspielen als wenn Du da immer über mehrere Ecken gehen musst. Ich setze mal voraus, dass Du auch Access zur Verfügung hast...?
Ich habe da aber auch schon Stunden voller Verzweiflung an solchen Datumsparametern gesessen

Gruß Thilo

MaThoPa1973 schrieb:

Danke für jeden der mir hilft die Augen zu öffnen.

Bitte suche nach "OleDBParameter" im Forum. Dieses String zusammenstückeln ist nämlich grausiger und fehlerträchtiger (hast du ja gerade gemerkt) SCH... !

Prinzipiell:
UPDATE tabelle SET feld = @neuwert WHERE anderesfeld = @testwert
Über die Parameters Eigenschaft des Command-Objekts kann man jetzt diesen VARIABLEN im SQL-String Werte zuweisen. Und man braucht sich nicht um Hochkommas, Datumsformate etc zu kümmern!

Hallo Zusammen,
@ErfinderdesRades: Ich bin wirklich für jeden guten Tipp dankbar - aber die Umstellung von VB6 nach VB2010 hat doch schon so einige Änderungen mit sich gebracht. Natürlich bin ich gewillt und bereit auch neues zu lernen aber ich versuche erst einmal streng getreu dem Motto "Schuster bleib bei deinen Leisten" mich auf alt bewährtes zurück zu greifen. Im Normalfall würde ich da auch weiter mit kommen. Natürlich werde ich aber auch gucken, dass ich mir in der Zwischenzeit Dein Sample ansehen werde aber dazu muss ich mich insgesamt mit der Materie noch ein wenig mehr befassen um auch zu verstehen was so im Allgemeinen hinten rum passiert denn sonst suche ich mir ewig und drei Tage bei jedem Schritt einen Wolf.

@ThisSoft: Natürlich habe ich auch Access zur Verfügung (Office Prof. 2010). In der Zwischenzeit habe ich auch einen Fehler gefunden. Leicht zu übersehen hatte ich zwischen dem letzten Update-Parameter und der Where-Klausel ein "," (Komma) stehen. Da musste natürlich der Syntax-Fehler kommen. Anschließend kam, wie zu erwarten ein Typ-Error bezogen auf den Datumswert und den habe ich mittels der Format und Replace ausbügeln können.

Das Kommando sieht jetzt wie folgt aus:

cmd.CommandText =
"Update PatData Set PatM = '" & Me.PatDatChg.CurrentRow.Cells(3).Value & "', " &
"PatKG = '" & Me.PatDatChg.CurrentRow.Cells(4).Value & "' " &
"WHERE PatName = '" & CStr(Me.PatDatChg.CurrentRow.Cells(0).Value) & "' " &
"AND PatVName = '" & CStr(Me.PatDatChg.CurrentRow.Cells(1).Value) & "' " &
"AND PatGDat = " & Replace("#" & Format(Me.PatDatChg.CurrentRow.Cells(2).Value, "dd/MM/yyyy") & "#", ".", "/")

Der Rest ist unverändert wie oben gezeigt. Dummerweise bekomme ich jetzt keinen Fehler mehr und das Programm läuft durch allerdings ohne dass der Datensatz geändert wurde. PatName, PatVName und PatGDat fungieren als Primärschlüssel und zum Test habe ich PatM und PatKG (Dezimalwerte) geändert was jedoch in der Zentral-DB nicht übernommen wurde. Ich flippe bald aus. Aber jetzt muss ich erst einmal auf die Schaff - und werde mich dann ganz entspannt Heute Abend an das nächste Problem begeben.

Also, dank Euch allen und einen schönen Tag.
Gruß
Markus

MaThoPa1973 schrieb:

streng getreu dem Motto "Schuster bleib bei deinen Leisten" mich auf alt bewährtes zurück zu greifen.

Dann bist du in .Net falsch. Hier ist alles ganz neu für dich.
Festhalten an Bewährtem führt dazu, dass du dir grauenhaft überholte Techniken aneignest und verfestigst.
Da kann man eiglich nur hoffen, dass du damit scheiterst, sodaß du gezwungen bist, die besseren Technologien zu erlernen. Häufig kommt man aber so schlecht und recht damit durch, und damit ist vorherbestimmt, dass man für alle Zeiten immer wieder nix als Schrott produziert.

...muss ich mich insgesamt mit der Materie noch ein wenig mehr befassen um auch zu verstehen was so im Allgemeinen hinten rum passiert denn sonst suche ich mir ewig und drei Tage bei jedem Schritt einen Wolf.

Da gibts keine Alternative zu, insbesondere die elende Sucherei für jedes Schrittchen.
Auch das Suchen kann man mehr oder weniger effizient machen: Möglichkeiten der Informationsgewinnung

Oder du lernst neu und im Zusammenhang: dieses Buch Lesen
Das empfehle ich sehr, denn das VS bietet Möglichkeiten, auf die du von selbst garnet kommst.

ErfinderDesRades schrieb:

Festhalten an Bewährtem führt dazu, dass du dir grauenhaft überholte Techniken aneignest und verfestigst.

Nicht zwangsläufig.
Ich fahre gerne mehrgleisig.

Alte, bewährte Systeme bearbeite ich gerne nach dem Motto "never touch a running system" und fasse sie nur sehr vorsichtig an.
Es ist einfach eine Frage der Stabilität und der Benutzerakzeptanz, in ein bestehendes System einzugreifen.
Abgesehen von der Tatsache, dass für ein Redesign selten Budget vorhanden ist.

Neue Projekte oder Redesigns alter Projekte werden ausschliesslich in moderner Architektur durchgezogen.

Aber auch da gibt es (leider) Ausnahmen:
Kürzlich kämpfte ich vergeblich für eine .NET-Architektur, da der Kunde keine geschulten Leute hatte, um später das Projekt zu übernehmen.
Ich hatte die Wahl, das Projekt sausen zu lassen oder mich anzupassen.
Manchmal treibt einen das Leben dann halt doch dazu, gegen seine innere Überzeugung zu handeln

Einen Vorteil hat diese Mehrgleisigkeit:
Man bleibt geistig flexibel.
Mir ist inzwischen auch egal, ob C# oder VB.Net. Es dauert nur ganz kurz, um in Gedanken in der richtigen Umgebung zu sein.
Auch der Switch von VB6 zu VB.Net ist kein Spagat, wenn man beide Umgebungen schon mal ausführlich kennengelernt hat.

Ich fahre gerne mit einem schnellen Wagen auf der Autobahn, aber es hat auch seinen Reiz, mit einem VW-Käfer eine Gebirgs-Tour zu machen.
Wichtig ist, dass man Spaß daran hat, mit den gegebenen Umständen klar zu kommen.

petaod schrieb:

ErfinderDesRades schrieb:

Festhalten an Bewährtem führt dazu, dass du dir grauenhaft überholte Techniken aneignest und verfestigst.

Nicht zwangsläufig.

Doch. so ziemlich zwangsläufig.

Wenn der TE sich jetzt hier eine "Lösung" ohne ADO.Net und ohne Databinding erarbeitet, wird er ziemlich sicher auf diesem Stand stehen bleiben.
Na, vlt. lernters auch später, aber eher unwarhscheinlich. Auch wird er dann zwangsläufig mit dem jetzigen sehr unzufrieden sein, wenner dessen unzulänglichkeit dann später ermessen kann (wie gesagt: falls er je soweit kommt).

Es ist bei ihm ja nicht so, dasser durch Kunden gezwungen wird, Steinzeit zu verwenden, sondern einzig durch seine Unkenntnis der bereitstehenden Techniken.
Und deine Flexiblität - beim einen Kunden Steinzeit - beim nächsten wieder ordentlich proggen, hatterja garnicht - mussersich ja erst erwerben.
Auch scheint mir das erklärte Ziel gerade ein vollständiges ReDesign zu sein, nach Stand der Technik, also auf so Klötze am Bein muss und soll ja gar keine Rücksicht genommen wern.

Auch scheint mir das erklärte Ziel gerade ein vollständiges ReDesign zu sein

In dem Fall gebe ich dir recht.
Dann gibt es keine Ausrede, nicht mit der neuesten Architektur zu arbeiten.
Abgesehen von der Zeitersparnis, die nach der Einarbeitungsphase erreicht wird, wird ihm das angeeignete Wissen später immer wieder zugute kommen.

Hallo Leute,
soweit klappt der Transfer von Datasets an die zentral-DB, jetzt verzweifel ich jedoch bei dem Versuch die Zentral-DB an die Lokal-DB zu übertragen und bekomme immer einen Datentypenkonflikt im Kriterienausdruck.
Beide Tabellen sind absolut identisch und die Typen sind im Dataset auch richtig hinterlegt.

' Lesen und übertragen der zentralen Tabelle PatData
cmd.Connection = con
cmd.CommandText = "SELECT PatName, PatVName, PatGDat, PatM, PatKG, INRH, INRL, TabDOS, " & _
"AmpKW, PatDiag, PatMed, PatStrasse, PatPLZ, PatOrt, PatFon, PatFax, DDD FROM PatData"

con.Open()
reader = cmd.ExecuteReader()

Do While reader.Read()
Me.INRMSDataSet.PatData.AddPatDataRow( _
reader("PatName"), _
reader("PatVName"), _
reader("PatGDat"), _
reader("PatM"), _
reader("PatKG"), _
reader("INRH"), _
reader("INRL"), _
reader("TabDOS"), _
reader("AmpKW"), _
reader("PatDiag"), _
reader("PatMed"), _
reader("PatStrasse"), _
reader("PatPLZ"), _
reader("PatOrt"), _
reader("PatFon"), _
reader("PatFax"), _
reader("DDD"))
Me.DGVPatData.Refresh()
Me.PatDataTableAdapter.Update(Me.INRMSDataSet.PatData)

Loop
reader.Close()
con.Close()

Könnt Ihr mir weiterhelfen?

Gruß
Markus

guckma, ich habmir jetzt maln Dataset aus einer DB generieren lassen, und der generiert auch einen TableAdapterManager, und dieser TableAdapterManager hat auch eine Connection-Property.

Das sieht also so aus, als könneman da ganz einfach eine annere Connection dranstöpseln, und dann geht das Dataset auf eine annere DB.

Das ist viel einfacher, als mein ChangeConnectionString-Hack. Ist was neues, mein ChangeConnectionString-Dings habichmir anno 2005 ausgedacht, und seither nichmehr mit beschäftigt.

Da täte ich mal mit rumprobieren.

auf jeden fall täte ich mich keinesfalls mit DataReadern herumärgern.

Ja, der DataReader ärgert mich gerade ganz schön... ist zum Mäuse melken.
1. Beide Datenbanken absolut identisch vom Aufbau weil kopiert
2. Der DataSet ist auch richtig eingetellt - da wo decimal, Date oder String sein soll (in der DB) ist es auch im DataSet... er zeigt mir auch wenn ich AddPatDataRow schreibe alle Parameter mit entsprechendem Typ an - umso verwunderlicher, dass da immer die Fehlermeldung kommt.

Verstehe ich Dich also richtig, wenn ich also einfach hingehe und einen weiteren DataSet erstelle und dem quasi den ConnectionString übergebe den ich aus der Systemdatei auslese? Wenn das so einfach wäre, dann wäre es ja prima.

Habe mir die 2 Tabellen der zentralen DB jetzt in das DataSet reingezogen aber wie und wo kann ich jetzt den ConnectionString im Programmcode abändern so, dass der ConnectionString während des Programmablaufs übergeben wird und die Verbindung zu den Tabellen hergestellt wird?

Wenn du die Tabellen aus dem Datenfenster aufs Form ziehst, kriegst du (neben dem BindingNavigator, der sofort zu löschen ist) einen TableAdapterManager hingeneriert, und der hat eine Read/Write - connection-Property.

Aber ich kann nicht versprechen, ob das wirklich die lösung ist, dem TableAdapterManager eine annere Connection anzudrehen. Aber probier das als erstes aus.

Wenn ich das so versuche...

INRMSZDBDataSetTableAdapters.TableAdapterManager.ConnectionStrings =

sagt er mir immer ConnectionStrings ist kein Member...

mein ObjectBrowser sagt:

Public Property Connection As System.Data.IDbConnection
Member von UpdateDB.MAAutoWertDataSetTableAdapters.TableAdapterManager

Ah - Du musst dich natürlich an den konkreten TableAdapterManager wenden, der auffm Form liegt - nicht an den INRMSZDBDataSetTableAdapters - Namespace

Hilfe - ich verzweifel hier so langsam...
Habe jetzt die Anbindung der Zentral-DB ebenfalls über ein DataSet laufen.

Mit Hilfe folgender Befehlszeile...
INRMSZDBDataSetTableAdapters.Connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;" & "Data Source=" & DBServString
bekomme ich die Verbindung im Laufe des Programms hergestellt und er beginnt mit der Übertragung und bricht genauso, wie zuvor, mit der Fehlermeldung "Datentypenkonflikt im Kriterienausdruck" den Vorgang wieder ab... zum Heulen.

Sehr erstaunlich.
Also auf die lokale DB kannst du zugreifen, solange du nicht am ConnectionString rumfummelst.

Dann stellst du den ConnectionString auf die zentrale DB um, und peng.

Aber beide DBs sind absolut identisch - ich nehme an, die lokale DB-Datei ist einfach zunächstmal eine Kopie der zentralen DB-Datei?

Richtig ! Die eine Datenbank ist eine Kopie der anderen und liegen an unterschiedlichen Orten.

Hat das überhaupt mit den verschiedenen DBs zu tun?
Also kannst du wenigstens Updaten, wenn du auf dieselbe lokale DB zurückschreibst?

Vlt. isses ja tatsächlich, was er sagt: ein "Datentypenkonflikt im Kriterien-Ausdruck" (was immerdas seinmag)