none
Access 2003: Datentyp Bit in ServerTable irgendwie nicht in Access bearbeitbar

    Frage

  • Hallo,

    im SQL Server 2008 Backend habe ich für ja/nein Felder den Datentyp bit. Tabellen sind per ODBC nach Access verknüpft. Ich öffne eine verknüpfte Tabelle in der Datenansicht ändere eine 0 in eine 1 (=>-1) und klicke in eine andere Zeile, so erhalte ich die Meldung Schreibkonflikt, siehe Screenshot.

    Ich bin aber definitiv der einzige User. Wo liegt da das Problem? Code ist im Formular auch keiner enthalten.

    Gruß Andreas

     


    http://www.AccessBlog.de
    Montag, 5. September 2011 07:06

Antworten

  • Hallo Andreas

    Andreas Vogt wrote:

    im SQL Server 2008 Backend habe ich für ja/nein Felder den Datentyp bit.
    Tabellen sind per ODBC nach Access verknüpft. Ich öffne eine verknüpfte
    Tabelle in der Datenansicht ändere eine 0 in eine 1 (=>-1) und klicke in
    eine andere Zeile, so erhalte ich die Meldung Schreibkonflikt, siehe
    Screenshot.

    <http://social.microsoft.com/Forums/getfile/8722/>

    Ich bin aber definitiv der einzige User. Wo liegt da das Problem? Code
    ist im Formular auch keiner enthalten.

    Bit gibt's in Access nicht. Dieses interpretiert das als Ja/Nein Feld, welches es selber als Long ablegt und dann entweder 0 oder -1 speichert.
    Was passiert nun, wenn du -1 in die Tabelle schreibst. Der SQL Server wandelt das in eine 1 um und was Du zurückerhälst, ist nicht das, was Du vermeintlich reingeschrieben hast. Daher meint nun Access, dass da jemand andrer bereits was rumgefummelt habe.

    Abhilfe:
    A Leg' ein Timestamp Feld in der Tabelle an und verknüpfe diese neu.
    B Schreibe nicht 0 und -1, sondern 0 und 1
    C Ändere den Datentypen auf dem SQL Server in einen INTEGER und verzichte auf Bit.

    Gruss
    Henry

    Montag, 5. September 2011 07:13
  • Am 05.09.2011 schrieb Andreas Vogt:

    der Fehler (etwas anderer Text) war auch im SQL Server Management Studio wenn man die Tabelle zur Bearbeitung öffnete, und aus einer 0 eine 1 machte und den DS wechselte. Insofern kann das mit deiner Erklärung nicht ganz stimmen - oder?

    Leg zusätzlich ein Timestamp Feld an, anschließend die Tabelle in
    Access neu verknüpfen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    • Als Antwort markiert Andreas Vogt Dienstag, 6. September 2011 06:46
    Montag, 5. September 2011 18:46
  • Hallo Henry,

    die Konvertierung ja/nein zu bit und umgekehrt funktioniert automatisch, das ist kein Problem.

    Die Lösung ist bei bit-Feldern mit der Eigenschaft "NOT NULL" zu arbeiten und 0 als Standardwert vorgeben.

    Das Problem dabei ist dass man in Tabellen mit Daten diese Eigenschaften nicht auf Not NULL setzen kann, also muss die Tabelle neu erstellt werden und die Daten neu eingefügt werden.

    Alternativ kann man natürlich auch mit Integer-Werten arbeiten, das stimmt.

    Gruß Andreas


    http://www.AccessBlog.de
    • Als Antwort markiert Andreas Vogt Montag, 5. September 2011 07:39
    Montag, 5. September 2011 07:39

Alle Antworten

  • Hallo Andreas

    Andreas Vogt wrote:

    im SQL Server 2008 Backend habe ich für ja/nein Felder den Datentyp bit.
    Tabellen sind per ODBC nach Access verknüpft. Ich öffne eine verknüpfte
    Tabelle in der Datenansicht ändere eine 0 in eine 1 (=>-1) und klicke in
    eine andere Zeile, so erhalte ich die Meldung Schreibkonflikt, siehe
    Screenshot.

    <http://social.microsoft.com/Forums/getfile/8722/>

    Ich bin aber definitiv der einzige User. Wo liegt da das Problem? Code
    ist im Formular auch keiner enthalten.

    Bit gibt's in Access nicht. Dieses interpretiert das als Ja/Nein Feld, welches es selber als Long ablegt und dann entweder 0 oder -1 speichert.
    Was passiert nun, wenn du -1 in die Tabelle schreibst. Der SQL Server wandelt das in eine 1 um und was Du zurückerhälst, ist nicht das, was Du vermeintlich reingeschrieben hast. Daher meint nun Access, dass da jemand andrer bereits was rumgefummelt habe.

    Abhilfe:
    A Leg' ein Timestamp Feld in der Tabelle an und verknüpfe diese neu.
    B Schreibe nicht 0 und -1, sondern 0 und 1
    C Ändere den Datentypen auf dem SQL Server in einen INTEGER und verzichte auf Bit.

    Gruss
    Henry

    Montag, 5. September 2011 07:13
  • Hallo Henry,

    die Konvertierung ja/nein zu bit und umgekehrt funktioniert automatisch, das ist kein Problem.

    Die Lösung ist bei bit-Feldern mit der Eigenschaft "NOT NULL" zu arbeiten und 0 als Standardwert vorgeben.

    Das Problem dabei ist dass man in Tabellen mit Daten diese Eigenschaften nicht auf Not NULL setzen kann, also muss die Tabelle neu erstellt werden und die Daten neu eingefügt werden.

    Alternativ kann man natürlich auch mit Integer-Werten arbeiten, das stimmt.

    Gruß Andreas


    http://www.AccessBlog.de
    • Als Antwort markiert Andreas Vogt Montag, 5. September 2011 07:39
    Montag, 5. September 2011 07:39
  • Vieleicht noch als Ergänzung,

    der Fehler (etwas anderer Text) war auch im SQL Server Management Studio wenn man die Tabelle zur Bearbeitung öffnete, und aus einer 0 eine 1 machte und den DS wechselte. Insofern kann das mit deiner Erklärung nicht ganz stimmen - oder?

    Gruß Andreas


    http://www.AccessBlog.de
    Montag, 5. September 2011 12:23
  • Am 05.09.2011 schrieb Andreas Vogt:

    der Fehler (etwas anderer Text) war auch im SQL Server Management Studio wenn man die Tabelle zur Bearbeitung öffnete, und aus einer 0 eine 1 machte und den DS wechselte. Insofern kann das mit deiner Erklärung nicht ganz stimmen - oder?

    Leg zusätzlich ein Timestamp Feld an, anschließend die Tabelle in
    Access neu verknüpfen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    • Als Antwort markiert Andreas Vogt Dienstag, 6. September 2011 06:46
    Montag, 5. September 2011 18:46
  • Hallo Andreas

    Das stimmt nicht. Wieso soll man nicht auf NOT NULL ändern können?!?

    [sql]
    ALTER TABLE DeineTabelle ALTER COLUMN DeinBitFeld BIT NOT NULL
    [/sql]
    tut problemlos, vorausgesetzt es hat keine NULL Werte drin, sonst gibts eine Meldung, die genau das aussagt, nämlich, dass die Spalte nicht auf NULL gesetzt werden kann, weil diese NULL Werte enthält.

    Abhilfe schaft hier ein UPDATE der Art
    [sql]
    UPDATE DeineTabelle SET DeinBitFeld = 0 WHERE DeinBitFeld IS NULL
    [/sql]

    Wenn Du mit Access arbeitest, ist es von Vorteil, wenn Du INTEGER auf dem SQL Server verwendest, da Access und VBA intern mit LONG arbeitet, wenn es Boolean Felder vor sich hat.

    Gruss
    Henry

    Dienstag, 6. September 2011 02:22
  • So, so, was kommt denn im SQL Server Management Studio für eine Meldung? Diese solltest Du schon lesen.

    Vielleicht steht da was wie "Invalid value for cell (row x, column y) und irgendwas mit ".Net Framework Data Type Boolean"? und "not recognized as Boolean"? Scheinbar erkennt das SSMS 1 und 0 nicht als Boolean?

    Im SQL Server Management Studio (2005) in der Tabellen Ansicht musst Du True oder False eingeben, nicht 0 oder 1, selbst wenn der SQL Server selbst kein True und False kennt. Das ist ein .NET Formular mit dem .NET Framework dahinter und hier haben die Entwickler wohl nicht ganz sauber konvertiert. Aber hier sollte man auch keine Daten ändern, sondern statt dessen eine Query schreiben, welche dann wieder mit 0 und 1 funktioniert.

    Gruss

    Henry

    Dienstag, 6. September 2011 02:28
  • Henry Habermacher wrote:

    eine Meldung, die genau das aussagt, nämlich, dass die Spalte nicht auf
    NULL gesetzt werden kann, weil diese NULL Werte enthält.

    Wer schenkt mir bitte NOT ;-)

    Gruss
    Henry

    Dienstag, 6. September 2011 04:16
  • Hallo,

    habs jetzt nochmals nachgestellt und folgenden Fehler erhalten:

    'tbl_Messwertgrenzen2'-Tabelle
    - Die Tabelle kann nicht geändert werden. 
    Der Wert NULL kann in die 'skip'-Spalte, 'Injektormontage1.dbo.Tmp_tbl_Messwertgrenzen2'-Tabelle nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT.
    Die Anweisung wurde beendet.

    Aber es wird wie du gesagt hast daran liegen dass vor der Änderung Null-Werte vorhanden sind. Ist ja eigentlich logisch. Der Tipp mit dem Timestamp-Feld hat aber sehr gut funktioniert, danke.

    Andreas

     


    http://www.AccessBlog.de
    Dienstag, 6. September 2011 06:43
  • Danke, das hat funktioniert.

    Andreas


    http://www.AccessBlog.de
    Dienstag, 6. September 2011 06:46