SQLException, MS Access: "COUNT-Feld ungültig."

schnuffie

Erfahrenes Mitglied
Hallo Experten,

ich bekomme die nachfolgende Fehlermeldung und kann leider damit garnichts anfangen:
Code:
java.sql.SQLException: [Microsoft][ODBC Microsoft Access Driver]COUNT-Feld ungültig.

Analog dem Thomas-Beispiel (http://www.tutorials.de/forum/java/224223-access-datenbankverbindung.html?highlight=Access#2) baue ich die Connection so auf:
Code:
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection connection = DriverManager.getConnection("jdbc:odbc:DRIVER={Microsoft Access Driver (*.mdb)};DBQ=d:/test/news.mdb");
Statement stmt = connection.createStatement();
stmt.execute("insert into news (title, text) values ('" + news.getTitle() + "', '" + news.getText() + "')");

Wie kann ich diese Exception abstellen? Wer kann mir helfen?
 

Anhänge

  • tabelle.gif
    tabelle.gif
    10,1 KB · Aufrufe: 148
Hallo!

Aus deinen Daten geht IMHO die Fehlerursache nicht hervor. Ich denke der Fehler passiert an anderer Stelle. Weiterhin solltest du Prepared Statements verwenden, dann brauchst du auch nicht dieses Umstaendliche manuelle Quoting...

Gruss Tom
 
Danke für die rasche Rückinfo, habe die Sache auf PreparedStatement umgebaut und bekomme nun einen anderen Fehler:

Fehler:
Code:
java.sql.SQLException: [Microsoft][ODBC Microsoft Access Driver] Syntaxfehler in der INSERT INTO-Anweisung.
at sun.jdbc.odbc.JdbcOdbc.createSQLException(JdbcOdbc.java:6958)
at sun.jdbc.odbc.JdbcOdbc.standardError(JdbcOdbc.java:7115)
at sun.jdbc.odbc.JdbcOdbc.SQLExecute(JdbcOdbc.java:3150)
at sun.jdbc.odbc.JdbcOdbcPreparedStatement.execute(JdbcOdbcPreparedStatement.java:214)

Umbau:
Code:
      String sql;
      if (news.getId() < 1) {
        sql = "insert into news (title, text) values (?, ?)";
      } else {
        sql = "update news set title = ?, text = ? where id = ?";
      }
      PreparedStatement stmt = connection.prepareStatement(sql);
      stmt.setString(1, news.getTitle());
      stmt.setString(2, news.getText());
      if (sql.startsWith("update")) {
        stmt.setLong(3, news.getId());
      }
      stmt.execute();

Selbst ohne Angabe der Tabellenspalten will's nicht funktionieren. Wo kann den nun noch ein Fehler liegen? :confused:
 
Hallo!

Da deine ID Spalte ein Primary key ist und kein Autowert Feld ist musst du eine ID angeben wenn du ein Insert versuchst. Weiterhin koennte es sein, dass dein Spaltenname "text" mit einem Access Schluesselwort kollidiert...

Gruss Tom
 
Nun bin ich schon schlauer.

Nachdem ich bemerkt habe, daß anscheinend "text" ein MS-Access-Schlüsselwort ist, habe ich die Spalte in "inhalt" umbenannt - und siehe da, ich bekomme einen anderen Fehler:

Code:
java.sql.SQLException: [Microsoft][ODBC Microsoft Access Driver]Optionales Feature wurde nicht implementiert.
at sun.jdbc.odbc.JdbcOdbc.createSQLException(JdbcOdbc.java:6958)
at sun.jdbc.odbc.JdbcOdbc.standardError(JdbcOdbc.java:7115)
at sun.jdbc.odbc.JdbcOdbc.SQLBindInParameterBigint(JdbcOdbc.java:1225)
at sun.jdbc.odbc.JdbcOdbcPreparedStatement.setLong(JdbcOdbcPreparedStatement.java:592)

Was soll das nun wieder heißen?

Irgendwie bin ich durch "Herumbasteln" darauf gekommen, daß MS-Access mit "long" ein Problem hat:
Code:
stmt.setLong(3, id);

Nachdem ich jetzt statt dieser Methode so tue, als ob ich einen String hätte, funktioniert's:
Code:
stmt.setString(3, String.valueOf(id));

*freu*
 
Hallo!

Warum einfach wenns auch kompliziert geht?....
Java:
   /**
 * 
 */
package de.tutorials;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;

/**
 * @author tom
 * 
 */
public class MSAccessExample {

	/**
	 * @param args
	 */
	public static void main(String[] args) throws Exception {
		Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
		Connection connection = DriverManager
				.getConnection("jdbc:odbc:DRIVER={Microsoft Access Driver (*.mdb)};DBQ=d:/db2.mdb");
		PreparedStatement preparedStatement = connection
				.prepareStatement("INSERT INTO test (id, textData,numericalData) values (?,?,?)");
		preparedStatement.setInt(1, 1);
		preparedStatement.setString(2, "abc");
		preparedStatement.setInt(3, 3000);
		preparedStatement.execute();
		preparedStatement.close();
		connection.close();
	}

}

Gruss Tom
 
...weil's mit "int" geht, aber nicht mit "long". Meine IDs könnten aber größer als der Integer-Wertebereich werden (= MS-Access-Datentyp "Long Integer")

Das scheint ein Treiberproblem zu sein. Mit dem "Kunstgriff" "setString(...)" kann ich dieses Problem übergehen. Wäre nur noch zu probieren, was passiert, wenn ich > Integer.MAX_VALUE übergebe...
 
Hallo!

...weil's mit "int" geht, aber nicht mit "long". Meine IDs könnten aber größer als der Integer-Wertebereich werden (= MS-Access-Datentyp "Long Integer")
Wie lange soll dein System denn halten? Aber du hast recht, wenn du jeden Tag 5883.516841095890410958904109589 News postest dann ist der Wertebereich nach 1000 Jahren aufgebraucht. Also an deiner Stelle wuerde ich auch unbedingt long verwenden... ;-) Insbesondere wuerde ich bei diesen Datenvolumina auf ein so robustes System wie MS Access setzen... und komm nun bloss nicht mit Y2K

Gruss Tom
 
:p - in Sachen MS-Access.

Die Grenze Integer.MAX_VALUE (=2147483647) würde für 1 News je Sekunde in ca. 35 Mill. min, ca. 596000 h, ca. 25000 Tagen oder ca. 68 Jahren aufgebraucht sein.

Natürlich wird für das Wirksystem keine MS-Access-DB genommen. Wieviele User später News einstellen werden (1000, 2000, 5000, ?) ist noch nicht raus.
Ob alles immer manuell erstellt wird? Ob die Anwendung solange läuft? Mich wird's nicht betreffen.

Da Speicherbedarf nicht mehr allzu teuer ist, könnte ein Long nicht schaden, oder? ;)
Von heute auf morgen gedacht, hätte ich auch ein Integer genommen - wer ganz kurz denk, kommt warscheinlich auch mit Byte aus... ;-]

Denken wir nur mal an das Jahr-2000-Problem, nur weil bei Datumswerten nicht weit genug gedacht wurde. In den 70ern und 80ern dachte man eben auch, die beiden Jahresstellen reichen, denn die Software läuft 2000 eh nicht mehr... Falsch gedacht.
 
Wir hatten vor einem Monat oder so Besuch von einer großen Catering Firma in Deutschland. Die stellen gerade ihr DOS Verwaltungsprogramm auf ein modernes Windows (3.1?) :) Programm um ..
 
Zurück