vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Blitzschnelles Erstellen von grafischen Diagrammen!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB.NET - Ein- und Umsteiger
Probleme mit SQL-Update wegen falschem Typen 
Autor: Tommi467
Datum: 12.10.18 10:12

Hallo zusammen,

ich habe eine Sub-Routine, die mir in einer Datenbank je nach Kriterium
ein Datenfeld ändern soll.

        UpdateData(ConnString, "UPDATE Logbook SET [eqsl_qsl_rcvd] = 'Y'  WHERE" & _
          "[CALL] LIKE '%" & SearchCall & _
                               "%' and [BAND] LIKE '%" & SearchBAND & "%' and" & _
                               "[qso_date] LIKE '%" & SearchDATE & "%';")
Bis hierhin funktioniert alles einwandfrei.
Jetzt muss ich aber noch ein weiteres Feld vergleich.

Eines noch vorweg: Ich kann die Datenbank nicht umformatieren,
gehört nicht zu meinem Hoheitsgebiet. Ich muss mit dem zurechtkommen, was vorliegt.

Bei diesem Feld handelt es sich um ein Uhrzeitfeld in dem die Uhrzeit
ohne Trennzeichen und als TEXT eingetragen sind. Also z.B. "1411" für 14:11.
Leider wird es noch etwas komplizierter, weil die gesuchte Uhrzeit in der
Datenbank um bis zu 5 Minuten schwanken kann.

Also habe ich den Source wie folgt erweitert:

        UpdateData(ConnString, "UPDATE Logbook SET [eqsl_qsl_rcvd] = 'Y'  WHERE" & _
          "[CALL] LIKE '%" & SearchCall & _
                               "%' and [BAND] LIKE '%" & SearchBAND & "%' and" & _
                               "[qso_date] LIKE '%" & SearchDATE & _
                               "%' and [time_on] Between " & SearchTime - 10 & _
                               " and " & SearchTime + 10 & ";")
Dabei habe ich leider nicht berücksichtigt, das es sich um ein Textfeld handelt und nicht um ein Integer-Feld.
Die Frage ist nun, ob ich das überhaupt noch irgendwie realisiert bekomme...

Für Hilfe (außer für Hinweise ich solle die DB ändern) wäre ich sehr dankbar.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: effeff
Datum: 12.10.18 18:35

Schau Dir mal die SQL-Funktionen CAST und CONVERT an.

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: Franki
Datum: 14.10.18 01:02

Hallo,

eine guten Hinweis hast du ja schon von effeff bekommen.
Aber nur Uhrzeit? Zur Berechnung von Zeitintervallen, Zeitdifferenzen usw. gehört auch immer ein Datum, denn sonst wird das nicht wirklich gut.

Wenn du z.B. nur die Uhrzeit hast, kannst du nicht unterscheiden ob zwischen deinem 1411 und 2011 nur ein paar Stunden liegen, aber zwischen 2300 und 0200 z.B. ein Tageswechsel ist. Wenn da noch ein Wochenende dazwischen ist zwischen den einelnen Uhrzeiten geht das auch schief wenn du kein dazugehörtiges Datum hast.

Aber dennoch, die einzig sinnvolle Arbeitsweise wäre die DB zu ändern so dass die Daten in entsprechenden Feldern stehen und nicht nur als Text. Ok, das kannst du nicht beeinflussen, aber du solltest es versuchen. Als GEGEBEN muss man als Programmierer eigentlich nichts so ohne weiteres hin nehmen, man kann schon die Gestaltung der Datenbasis in gewisser Weise argumentativ mit bestimmen in den meisten Fällen, sei es über den Preis.

Ich sage meinen Kunden immer so etwas in der Richtung, dass wenn die Datenbasis nicht passt die Programmierung teuerer wird weil mehr Aufwand. Das dauert eine Weile, aber nach ein paar Demos sehen die das zu 98% ein, dass das auf Dauer billiger ist mit entsprechender DB Basis zu arbeiten. Wenn Fremdprogramme für die Datenbasis sorgen, dann plädiere ich immer dazu den Hersteller dazu zu verpflichten über ein Update dafür zu sorgen, dass das passt. Meistens geht es, wenn nicht, dann muss der Kunde halt den Mehraufwand bezahlen.

Aber wenn die Datenbasis unzureichend ist (hier nur Uhrzeit ohne Datum), diese auch nicht geändert werden kann, dann lehne ich den Auftrag kategorisch ab, da ich nur dann zuverlässige Berechnungen durchführen kann wenn Zeiten auch ein Datum beinhalten.

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: Tommi467
Datum: 14.10.18 13:41

Hallo Frank,

vielen Dank für den Tipp... aber schau mal
in die SQL Abfrage rein. Datum ist schon drin
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: Manfred X
Datum: 14.10.18 14:01

Hallo!

Ich kenne die Zeitangaben in der Datenbank nicht.
Der Hinweis von Franki ist vermutlich nicht zu ignorieren.
Angenommen in der DB oder in der Benutzervorgabe steht "2358".
Wen Du ein 10-Minutenintervall bei der Auswahl berücksichtigen
willst, gilt es, den Tageswechsel zu beachten.

Du solltest Datum und Uhrzeit in der Abfrage kombinieren.

Beitrag wurde zuletzt am 14.10.18 um 14:06:25 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: Tommi467
Datum: 15.10.18 13:51

Ich habe da jetzt mal ein bisschen in Cast und convert eingelesen,
aber mit der Umsetzung mag es nicht so richtig funktionieren:

UPDATE Logbook SET [eqsl_qsl_rcvd] = 'Y'  WHERE [CALL] LIKE '%ABCDE%' and _
  [BAND] LIKE '%XYZ%' and [qso_date] LIKE '%20180130%' and [time_on] Between ( _
  CAST( 1835 as int)-10) and (cast( 1835 as int)+10);
Es erscheint der Fehler: Syntaxfehler (fehlender Operator) in Abfrageausdruck

Bei Convert bekomme ich direkt eine Fehlermeldung: Undefinierte Funktion 'CONVERT' in Ausdruck.

Beitrag wurde zuletzt am 15.10.18 um 14:08:27 editiert.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: Franki
Datum: 15.10.18 23:41

Hallo,
ok ist drin, aber auch nur als Textfeld. Damit hast du dann das gleiche Problem wie bei der Uhrzeit.
Du selbst schreibst ja, dass die Uhrzeit um +- variieren kann. Passt sich das Datum in diesem Fall denn an? Also 00:02 Uhr an einem Datum minus 5 Minuten ergibt ein anderes Datum. (Kann sogar einen Monatswechsel oder Jahreswechsel bedeuten, ganz zu schweigen von Uhrzeitdifferenzen die die Umstellung von MEZ auf MESZ oder umgegehrt).

Dazu kommt noch, dass du bisher nicht geschrieben hast um welche DB es sich handelt. Die SQL Abfrage muss ja zur DB passen. Die Umwandlungsfunktionen können auch schief laufen. bei Monat und Tag z.B. 02.03 kann es sich je nach DB um den 2. März oder den 3. Februar handeln. Beides wird durch die Umwandlungsfunktionen abgedeckt, aber das geht schief wenn die Monatszahl über die 12 hinaus geht.

Wenn du rein mit Textfeldern arbeiten musst und das nicht ändern kannst, dann bleibt eigentlich als sichere Möglichkeit nur die entsprechenden Strings Schritt für Schritt auseinander zu nehmen, neu zusammen zu bauen in z.B. einer Variablen (oder besser noch gleich in die DB zu sepeichern im entsprechenden Datum/Uhrzeit Format und dann erst die SQL Abfrage drauf los zu lassen.

Ich weiß nicht wie die Daten in deine DB kommen. (welche Datenmenge in welchem Zeitraum) Wenn du irgendwelche Dateinen einlesen kannst oder Routinen laufen lassen kannst die nur neue Einträge auslesen, schlage ich vor dort schon anzusetzten und in ein zusätzliches Feld ein voll qualifiziertes Datum mit Uhrzeit zu speichern. Das ist schnell erledigt, beinhaltet jeweils nur wenige Datensätze. Und danach hast du die einfache und vollumfängliche Möglichkeit der SQL Abfrage auf das neue Feld zur Verfügung ohne irgendwelche Tricksereien.

Altbestände in der DB musst du halt einmal durchlaufen lassen, selbst wenn es ein paar Stunden dauert, der Aufwand lohnt sich.

Das Problem ist ja nicht neu, damit hatte ich schon unter Win95 mit Access/SQL Server DB unter VBClassic zu tun.

Gruß und viel Erfolg,

Frank

Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: Tommi467
Datum: 16.10.18 06:54

Hallo Frank,
ist nett, das du mich auf mögliche Datumswechsel aufmerksam machst,
das ist mir auch bewusst, aber die kann ich vorerst einmal ignorieren.

Es handelt sich bei der DB um eine Access ACCDB. Zuwachs im Monat etwa
300-500 Datensätze (bei 55 Felder).

Ich kann auch in möglichen Routinen oder Tools die Daten nicht einfach
konvertieren. Ich bekomme die Daten in dem genannten Format und muss
sie auch in diesem Format wieder weitergeben.
Klar, ich könnte jetzt auch für den Export wieder Routinen fertig machen
aber das ist mir einfach zu aufwändig.

Solange ich die BETWEEN-FUNKTION nicht ans laufen bekomme, habe ich mir
mit einem anderen Weg beholfen.

Provisorisch arbeite ich mit einem Reader, der mir zunächst ohne Uhrzeit
filtert. In der daraus resultierenden Liste wird dann die Uhrzeit untersucht.
Das geht hier einfacher, da ich ja vom Reader aus direkt konvertieren kann.
Passt die Uhrzeit +-5 Minuten, wird die ID ausgelesen und die Updatefunktion
kann dann direkt die ID aufrufen und ändern.

Etwas umständlicher aber es geht. Ein- zwei mal im Monat kommt es nicht auf
plus 20-30 Sekunden mehr an.
Schöner wäre es mit der Between Funktion, klar, aber in erster Linien brauche
eine funktionierende Lösung.
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: effeff
Datum: 16.10.18 12:01

CAST und CONVERT gibt es meiner Meinung nach nur in SQL-Server. Die Art der DB hattes Du leider nicht mit angegeben.

EALA FREYA FRESENA

Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Re: Probleme mit SQL-Update wegen falschem Typen 
Autor: Franki
Datum: 18.10.18 01:30

Hallo,
mit deinem Provisiorium bist du ja schon auf dem richtigen Weg, bzw. kannst das Problem lösen.
Bau die das für dem Im- und Export in eine Funktion, Modul oder sonst was ein danach kannst du innerhalb der Datenbank mit vernünftigem SQL arbeiten wie du es möchtest.

Bei der geringen Datenmenge pro Zeitrauf ist das ein vertretbarer Aufwand meiner Meinung nach.
Du kannst die Rohdaten ja in der DB speichern, das zustäzliche Feld dient dann der internen Verarbeitung in der DB. Wenn du A importierst, in X umwandelst aber A wieder ausgeben musst, dann kann A so bleiben wie es ist. Aber mit X kannst du beliebig rechnen.

Seit es Programmiersprachen gibt die externe Daten verarbeiten können hat man dieses Problem dass die Daten eigentlich nicht wirklich "passen", und man oft keinen Einfluss darauf hat. Daran wird sich auch wahrscheinlich in Zukunft nichts ändern wenn man keine Vorgaben machen kann.


Gruß
Frank
Themenbaum einblendenGesamtübersicht  |  Zum Thema  |  Suchen

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel