[SQL/JAVA] DB wordt pas geupdate bij afsluiten

Pagina: 1
Acties:

  • Goldme
  • Registratie: September 2000
  • Laatst online: 29-08 13:40
Ik probeer via java en JDBC een msaccess-database aan te spreken.leesopdrachten voert ie goed, schrijfopdrachten(bijv. insert) worden echter niet ingevoerd.

De eerste keer dat een insert wordt uitgevoerd wordt er niks in de DB ingevoerd, als er in dezelfde sessie nog een keer een insert wordt uitgevoerd dan wordt de vorige update ingevoerd en deze laatste weer niet. Het is een soort buffer dus van 1.

Wat ik ook kan doen is connectie.close() en dan worden de gegevens ok ingevoerd(geflushed zeg maar). Dit vind ik inefficient aangezien er steeds een connectie open moet bij elke aanroep voor de database.

Wat kan er fout zijn? waarom voert ie de insert niet gelijk uit? kan de connectie niet openblijven en de data gelijk weggeschreven worden?

  • The - DDD
  • Registratie: Januari 2000
  • Laatst online: 03-09 16:40
commit

Zoek is wat info over transacties en commit momenten en kijk hoe je het geconfigureerd hebt, in je source code of anders bij je ODBC bridge.

  • Goldme
  • Registratie: September 2000
  • Laatst online: 29-08 13:40
autocommit staat aan in de connectie klasse. Daar kan het dus niet aan liggen.

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Hum ik heb nooit commit problemen gehad met MS Access... Laat eens wat code zien?

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


  • The - DDD
  • Registratie: Januari 2000
  • Laatst online: 03-09 16:40
Open je toevallig de database met access zelf om te kijken of het er al in staat?

En als je dat doet, hoe doe je dat. Access open terwijl je bezig bent of.. ?

  • Goldme
  • Registratie: September 2000
  • Laatst online: 29-08 13:40
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    try
        {
            Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");
        }
        catch(java.lang.ClassNotFoundException e)
        {
            System.err.print("De class ODBC kon niet worden gevonden");
            System.err.println(e.getMessage());
        }
        try
        {
            connectie = DriverManager.getConnection ("jdbc:odbc:feestenEnzo",userName,password);
        }
        catch(SQLException e)
        {
            System.err.println("SQL fout" + e.getMessage());
        }

Vervolgens doe ik dit:
code:
1
2
3
4
Statement query= connectie.createStatement();
query.executeUpdate("insert into Klanten (bedrijfID,naam,adres,postcode,plaats,telNr,opmerkingen,emailAdres) values ("een hele string tekst die de layout verneukte");
query.close();
return true;

Als ik dit doe dan schrijft ie niks weg, als ik onder de eerste insert nog eenzelfde insert toevoeg dan schrijft ie de eerste weg maar de 2e is dan nog niet weggeschreven. Gebeurt pas als ik connectie.close() aanroep.

Maar dat wil ik niet aangezien ik de connectie in de eerste code open wil houden. Lijkt me inefficient om de connectie bij elke SQL-statement weer te sluiten na gebruik en dan weer te openen bij een volgende aanroep.

Sjezus, de layout is helemaal verneukt.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Bedoel je dat je in access niet ziet dat je met je programma iets hebt veranderd? Ik werk zo nu en dan ook nog wel eens met het beestje (omdat het op zich best wel redelijk werk vanuit het lekker snel/lui oogpunt :) ) Je moet even de db in access sluiten, je programma draaien, en dan de database weer openen. Dan zul je zien dat de record wel degelijk zijn ingevoegd. Access heeft schijnbaar zelf niet in de gaten of er iets is veranderd :+

Ik zit alles nog even na te lezen en ik betwijfel of het een antwoord op je vraag is :)

  • Goldme
  • Registratie: September 2000
  • Laatst online: 29-08 13:40
Ik heb hem maar aangepast zo dat hij de connectie sluit na elke SQL-opdracht. Is op zich niet erg aangezien het niet vaak zal voorkomen dat de connectie open moet blijven. Leek me wel wat netter.

  • The - DDD
  • Registratie: Januari 2000
  • Laatst online: 03-09 16:40
Op woensdag 16 januari 2002 00:34 schreef Goldme het volgende:
Ik heb hem maar aangepast zo dat hij de connectie sluit na elke SQL-opdracht. Is op zich niet erg aangezien het niet vaak zal voorkomen dat de connectie open moet blijven. Leek me wel wat netter.
Inderdaad, als je de connectie voor langere tijd niet gebruikt is het een goed idee om hem te sluiten. Maar let er wel op dat connecten naar een database een dure operatie is, zowel wat betreft tijdsduur als de nodzakkelijke bronnen die aangesproken worden. Er moet een TCP verbinding gelegd worden, geconnect worden naar de DB deamon, authorisatie, en wie weet zit er nog een of ander verleutelings verhaal of token uitwisseling bij. Duur dus. Niet iets wat je in een korte loop wil herhalen.

  • The - DDD
  • Registratie: Januari 2000
  • Laatst online: 03-09 16:40
Op woensdag 16 januari 2002 00:05 schreef Alarmnummer het volgende:
Bedoel je dat je in access niet ziet dat je met je programma iets hebt veranderd? Ik werk zo nu en dan ook nog wel eens met het beestje (omdat het op zich best wel redelijk werk vanuit het lekker snel/lui oogpunt :) ) Je moet even de db in access sluiten, je programma draaien, en dan de database weer openen. Dan zul je zien dat de record wel degelijk zijn ingevoegd. Access heeft schijnbaar zelf niet in de gaten of er iets is veranderd :+

Ik zit alles nog even na te lezen en ik betwijfel of het een antwoord op je vraag is :)
En het leuke is (mits je een thin java JDBC driver gebruikt) dat het daarna een kwestie is van 1 configuratie item veranderen (de driver string en eventuele authorisatie) en je kan het op een productie DB draaien.

Indien mogelijk kies ik ook altijd voor thin JDBC, 't is namelijk snel, uniform, platformonafhankelijk (niet java JDBC drivers willen nog wel is platform specifiek zijn) en makkelijk uitwisselbaar met andere DB leveranciers.

Wel even opletten of de DB de vereiste capaciteiten heeft. Meerdere connecties op MySQL die dezelfde tabellen gebruiken, wil nog wel is ranzig werken.
Pagina: 1