problem z zapisem Date (baza mysql i postgres)

hej,
korzystajac z JDBC musze zapisac date. mam 2 bazy-jedna to postgres, druga to mysql. Pole do ktorego zapisuje ma typ date (zarowno w postgresie jak i mysql). Po stronie javy mam date w formacie Calendar. i probuje zapisac w ten sposob:

Calendar c = ... //tutaj ta moja data

String sql = "INSERT INTO test(data_test) VALUES('"+c.getTime()+"')";
 

Jak sobie wypisze na konsole c.getTime() to mam:

Sat Feb 19 00:00:00 CET 2011

i teraz tak-postgres sobie z tym radzi i wstawia mi date: 2011-02-11

zas mysql sobie nie radzi, wywala:
com.mysql.jdbc.MysqlDataTruncation: Data truncation: Incorrect date value: '
Feb 19 00:00:00 CET 2011' for column 'data_test' at row 1

czyli sobie nie radzi. format w mysql mam YYYY-MM-DD.

czy ja to musze konwertowac do Stringa i podawac mu '2011-02-11'?

bede wdzieczna za wszystkie rady,
pzdr

    misty

Po pierwsze PREPARETD STATMENT UŻYWAJ BO CI KTOŚ KOD W SQLKĘ WSTRZELI I SIĘ OBUDZISZ Z RĘKOMA W NOCNIKU!!!

Po drugie do pracy z datami służą klasy java.sql.Date i java.sql.Timestamp mapujące się na typy date i tamestamp w bazie. Powinnaś zrobić tak:

PreparedStatement preparedStatement = connection.prepareStatement("NSERT INTO test(data_test) VALUES(?)");
		preparedStatement.setDate(1, new Date(c.getTime()));
		preparedStatement.executeUpdate();

wiesz co, ale PreparedStatement to mam w miejscach gdzie moge re-uzywac zapytania. jak to jest zwykle select jedno pole albo insert jedno pole to mam mam zwykly Statement...

to jest na prawde az takie niepoprawne?

To nie jest kwestia niepoprawności tylko bezpieczeństwa i dobrych praktyk. Poza tym PS pozwalają na lepsze zarządzanie typami takimi jak daty właśnie. Swoją drogą możesz sobie napisać małą maszynkę do generowania zapytań, która zwracała by PS na podstawie zapytania + listy parametrów...

tak, zastosuje sie do Twoich rad.

dzieki :)

wiesz co, napotkalam jednak maly problem. no bo po zapisie, potrzebowalam id ostatnio zapisanego rekordu. i maja Statement robilam to w nastepujacy sposob:

 
      Statement st = conn.createStatement();
      st.executeUpdate(sql.toString(), Statement.RETURN_GENERATED_KEYS);

      /* pobierz id */
      ResultSet rs = rs = st.getGeneratedKeys();
      if (rs.next()) {
        id = rs.getInt(1);
      }

w PreparedStatement jest inaczej-no bo czesc zapytania juz w nim przygotowuje, pozniej w odpowiednim miejscu uzupelniam ? wartosciami, czyli normalnie mam:

preparedStatement.executeUpdate().. owszem jest rowniez to executeUpdate(String sql, int autoGeneratedKeys) no ale to wlasnie wymaga podania ode mnie sqla, a tego przeciez mam juz w tym obiekcie przygotowanego. Wiesz moze jak moge w tym przypadku pobrac ostatnie zapisane id?

pzdr,
misty

ale ze mnie ciapa!
przeciez on ma metode getGeneratedKeys() :)

wiesz co, ja cos jednak chyba namieszalam. wiec tak-mam teraz PreparedStatement. w odpowiednim miejscu uzupelniam znaki zapytania poprzez setInt/setString itd. potem wykonuje zapytanie no i chce pobrac ost zapisane id:

 
  prepSt.executeUpdate();
      /* pobierz id */
      ResultSet rs = rs = prepSt.getGeneratedKeys();
      if (rs.next()) {
        id = rs.getInt(1);
      }

no i wcale nie zwraca mi tego ostatniego id! dla zwykledo Statementu to bylo:

 
     Statement st = conn.createStatement();
      st.executeUpdate(sql.toString(), Statement.RETURN_GENERATED_KEYS);

no i wtedy mi dzialalo getGeneratedKeys(). Dla PrepSt tez jest executeUpdate w ktorym moge podac sqla i Statement.RETURN_GENERATED_KEYS no ale przeciez chodzi o to, by nie podawac sqla w stringu, tylko by miec PrepSt i za pomoca setow ustawic wartosci.. kurde, mam nadz ze nie zamotalam tego o co mi chodzi. no ale wlasnie-jak mam pobrac wygenerowane id w przypadku uzycia PreparedStatement?

   pzdr,
         misty

Koziolek, ja mam do Ciebie jeszcze pytanie-w PreparedStatement to ja nie moge sie wpiac? tzn. podajac argumenty poprzez np setString rowniez moge
sobie podac tam fragment sql'a i w sumie tak samo moge sobie klopotow narobic bo to bedzie podstawione pod jeden z parametrow. W czym wiec PreparedStatement bedzie tutaj bezpieczniejszy?

pzdr

przy uzyciu preparedStatement już jdbc się zajmuje sql injectami.

misty napisał(a)

Koziolek, ja mam do Ciebie jeszcze pytanie-w PreparedStatement to ja nie moge sie wpiac? tzn. podajac argumenty poprzez np setString rowniez moge
sobie podac tam fragment sql'a i w sumie tak samo moge sobie klopotow narobic bo to bedzie podstawione pod jeden z parametrow. W czym wiec PreparedStatement bedzie tutaj bezpieczniejszy?

pzdr

W tym ze escapuje podane stringi i nie ma możliwości aby wstrzelić sie w sql.Przykład:

SELECT * from users where name = $1

Jeśli interesuje Cie user na nazwie John to nie musisz podac dodatkowych ciapek ( apostrofów ) aby uzyskac SQL końcowy SELECT * from users where name = 'John'. Co za tym idzie wklejenie ciągu ';DROP TABLE users skończy sie tym że na bazie odpalony zostanie sql o tresci SELECT * from users where name = '';DROP TABLE users'.

Teraz widzisz róznice?

dzieki!