Tomt resultset...?? Hvorfor??

du henter vel data med rs.get... ?

Jo og således:

while (rs.next())
      {
        ServPakOrdre servPakOrdre = tjek(rs);
        servPakOrdreListe.addServPakOrdre(servPakOrdre);
      }

Jeg opretter objekter på baggrund af mit resultset...

Jeg er offline den næste time men kommer tilbage derefter.. Mvh Casualty

private ServPakOrdre tjek(ResultSet rs) throws SQLException
  {
      int id = rs.getInt(1);           
      ServPakOrdre servPakOrdre = ServPakOrdreMap.getInstance().getServPakOrdre(id);
      if (servPakOrdre != null)
        return servPakOrdre;
      else
      {
        servPakOrdre = new ServPakOrdre(id,rs.getInt(2));                                       
        ServPakOrdreMap.getInstance().addServPakOrdre(servPakOrdre);
      }
     
      return servPakOrdre;
  }

Når ingen andre vil, så prøv om dette kan bruges, jeg ved ikke hvad
ServPakOrdreMap.getInstance().getServPakOrdre(id); gør.

Men sådan ville jeg nok løse/prøve det !

ServPakOrdre servPakOrdre;

while (rs.next())
      {
        servPakOrdre = tjek(rs);
        servPakOrdreListe.addServPakOrdre(servPakOrdre);
        servPakOrdre = null;
      }

private ServPakOrdre tjek(ResultSet rs) throws SQLException
  {
      int id = rs.getInt(1);           
      servPakOrdre = ServPakOrdreMap.getInstance().getServPakOrdre(id);
      if (servPakOrdre != null)
        return new servPakOrdre; // Tror du mangler "new" her !
      else
      {
        servPakOrdre = new ServPakOrdre(id,rs.getInt(2));
        ServPakOrdreMap.getInstance().addServPakOrdre(servPakOrdre);
        return servPakOrdre; // Dette mere af hensyn til logikken
      }
  }

Tak for kommentaren carsten.
***ServPakOrdreMap.getInstance().getServPakOrdre(id);***
Er en metode der tjekker om objekter allerede eksisterer i rammen(via en mapKlasse)og prøver at undgå redundans i mine data, ved at returnere dette objekt hvis det som sagt allerede eksisterer, istedet for bare at skabe et nyt...

Anyway Så ligger fejlen ikke her, jeg har bare taget metoderne med for at danne et sammenhæng.
Problemet allerede når jeg laver et resultset ud fra min query via. mit statement...Resultsettet er tomt når jeg får det...Det mærkelige er at hvis jeg fyrer mit sql kald af i en prompt, så får jeg et resultat tilbage??

Hvad med at lave et lille standalone test program som tester queryen.

Så fjerner du dele af querien gradvist for at finde ud af hvilken
del der driller gennem JDBC.

Mit personlige gæt vil være at det er datoerne der driller og at
en PreparedStatement og setDate vill hjælpe.

Tak Arne_v
Jeg skilte det ad og kunne konstatere at problemet ligger i datohåndteringen..
Kan du ikke uddybe setdate?
Det virker nu hvis jeg fjerner datokriterierne...Men det er vigtigt at jeg har dem med, så hvordan håndterer jeg dette?

Mvh Casualty

Med PreparedStatement kan du jo skrive:

"... between ? and ? ..."

i din SQL streng og så bruge:

pstmt.setDate(index, dato);

så tror jeg problemet forsvinder.

Helt ligesom når det fjerner problemer med strenge med ' i.

Men inden du går igang med PreparedStatement kan du jo evt. lige
prøve med:

between '03-Jul-05' and '03-AUG-05'

for at checke om det er noget så banalt at JDBC driveren tænker YY-MMM-DD.

Boom...Der var den....Lækkert...Problemet lå i JDBC´en Hvorfor i alverden bytter den rundt på den måde??

Nu er det løst...10.000 tak for hjælpen..Smid lige et svar :)

svar

Det er mange år siden jeg opgav at forstå datoer i SQL.

Det er håbløst.

Vær opmærksom på at på naboens PC kan det godt være anderledes,
fordi han kører med en anden Windows/Java/Oracle/whatever opsætning.

setDate virker altid fordi input er et binært tal ikke en
formateret tekst-streng.

Det er jo vanvid at der ikke er bare én eller anden form for standart på det punkt...

>>setDate det er i det mindste smart..

Jeg tror det er sket i "brugervenlighedens" tegn.

For at gøre det naturligt for brugerne vil man bruge det dato-format
som de kender og foretrækker.

Så det kan konfigureres.

Der ER en standard for datoformat - i USA.
Og én i Europa, én i Japan, én i Australien osv...!

Det er et genoldigt rod, som har været der i mange år, men først er blevet et rigtigt problem med computernes - og specielt med internettets - indtog. For det er jo ikke kun datoer, der er rod med: hvad med æ/ø/å? Og noget så banalt som tal: på Amerikansk ville du skrive 1,000.00 - men hvis din danske Excel skulle læse tallet, ville det jo gerne have haft 1.000,00 ...;)
Find lige en løsning på problemet, og når du har gjort det, så fortæl lige amerikanerne at de skal tanke liter på deres biler i stedet for gallon. Når du er i gang, kan du jo passende fortælle svenskerne at en mil ikke er 10 kilometer, og at de i øvrigt burde måle i kilometer. Så kan du tage fat på englænderne, og fortælle dem at de skal køre i højre side. Og Danskerne, at det hedder hektogram og ikke 100g...
Når du har løst alle disse problemer, så skriv lige til mig. Så har du sikkert også gættet min emailadresse, der er jo ikke så mange at vælge imellem derude...;)

Nej det er sgu ikke let når man prøver at gøre en kæmpe verden lille..
Du har fat i noget der.. :)

Tjae, hvis det så bare var en kæmpe verden, så var det til at løse...Tag nu bare byen Aalborg: her staves bynavnet, som det er blevet stavet i århundreder. Bevæg dig så 100km sydpå, og i Århus er der pludselig indført et helt nyt bogstav - for en menneskealder siden! Hvordan kan du så forvente at nogen skulle kunne blive enige om enheder? Det er nok derfor, at demokrati fungerer bedst i teorien - præcis som socialisme...og enevælde for den sags skyld...

Men hvis du er helt vild for at få lov til at rende panden mod en mur af uvidenhed og forstokkethed, så kan du jo bare blande dig med W3C-guruerne. De mener at have fundet "standardEN" for www. Dér er nok at tage fat på - og ikke ret mange til at gøre det...;)

(Jeg kunne ikke lade være, "de" er så prikne at man MÅ prikke til dem en gang i mellem!)

Datoer er dog være end det meste.

Tænk på 01-02-03 ! Er det 1. februar 2003 ? 2. januar 2003 ? 3. februar 2001 ?

Hov-hov! Hvordan kan du tillade dig at antage, at datoen er i dette årtusinde? ;)

Nå, men I får vel ikke løst standard-problemerne før i morgen.
Og nu kalder hende med pelsen, så-øeh jeg vil citere en kendt daner:

"I morgen er der atter en dag...!"