[C#/ODBC/MySQL] OdbcDataReader.getBytes vind niets

Pagina: 1
Acties:

  • roy-t
  • Registratie: Oktober 2004
  • Laatst online: 17-10 16:43
Ik ben al een tijdje bezig met een C# applicatie die verbinding maakt met een MySQL database via ODBC. Dit werkt allemaal prima en snel, en data opslaan en ophalen gaan erg goed. Maar nu wil ik graag bestanden opslaan (<16MB) in de database in een BLOB veld.

De volgende tabel gaan ze in:
Afbeeldingslocatie: http://i30.tinypic.com/2cxwxte.jpg

opslaan gaat prima door via ODBC een parameterized query te maken en als paramater voor veld bestand netjes een bytearray mee geven. In MySQL Query browser kan ik dan netjes het bestand zien ("BLOB") en het bestand zelfs downloaden (handige util) en dan komt er inderdaad exact het bestand uit wat ik erin heb gestopt.

Echter nu wil ik de bestanden uit gaan lezen. De volgende code leek me logisch en staat bijna het zelfde in de MSDN

C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//Even de Try's e.d. weggehaald om ruimte te besparen
public byte[] Download(string table, string uid)
        {
            OdbcCommand getFileSize = new OdbcCommand("select * from " + table + " where uid = ?", odbcConnection);
            getFileSize.Parameters.Add(new OdbcParameter(String.Empty, uid));
            Table ft = Select(getFileSize); //eigen Class die een tabel voorstelt
            string[] row = ft.getRow(0);     //krijg de goede rij
            int size = Int32.Parse(row[2]); //en haal daaruit de grote van het bestand

            OdbcCommand getFile = new OdbcCommand("select * from " + table + " where uid = ?", odbcConnection);

            getFile.Parameters.Add(new OdbcParameter(String.Empty, uid));
            byte[] file = null;
            odbcConnection.Open();
            OdbcDataReader reader = getFile.ExecuteReader(System.Data.CommandBehavior.SequentialAccess);
            reader.GetBytes(3, 0, file, 0, size);                                  
//sluit code weggehaald
           return file;
        }


De grote ophalen gaat goed (via debugging de waarde van size bekeken)

De rij die opgehaald wordt is rij 4, en bij het debugging zie ik netjes dat die 6 kollomen heeft (in de reader) maar als ik dan row 3 probeer te lezen gaat het fout. Ik krijg de melding dat er geen data aanwezig is in die kolom. Zerobased is 3 de 4e kolom en dat klopt (volgende de comments is getBytes zero-based). Ook zomaar een andere kolomwaarde invoeren helpt niet, terwijl er gewoon zeker "iets" moet zijn. immers staat in elke kolom iets.

Ik heb gegoogled een daar heeft iemand het zelfde probleem. Volgens hem werkte het wel goed in .NET1.1 maar dat heb ik nooit geprobeerd. Zijn probleem wordt helaas niet opgelost. Als ik verder de MSDN examples van getBytes bekijk zie ik geen magisch andere code. (het is ook slechts 1 statement natuurlijk).

Ik ben nu 2 uur bezig geweest met die paar regels code maar ik blijf geen data krijgen maar een foutmelding dat er geen data is. Heeft iemand een idee waar het kan zitten?

~ Mijn prog blog!


  • roy-t
  • Registratie: Oktober 2004
  • Laatst online: 17-10 16:43
Arg! De volgende dag nog een keer naar het voorbeeld op MSDN gekeken met een weer helder hoofd.

Een kleine wijziging hielp:

C#:
1
2
3
4
while (reader.Read())
                {                    
                    file = (byte[])reader.GetValue(3);
                }


Dus reader.read() erbij ook al is er maar 1 rij. En ik heb ipv getbytes getValue() gebruikt, en die gecast naar een bytearray. Dit werkt makkelijker omdat je geen rekening hoeft te houden met het feit dat getBytes maximaal een intwaarde kan gebruiken om te lezen en dus maximaal +- 2MB kan lezen.

EDIT: 2e kleine fout die ik tegen kwam en handig is als iemand het zoekt. Als je de waarschuwing krijgt "De verbinding is gesloten" of een andere foutmelding bij het uploaden van BLOB / byte[] data groter dan 1MB dan staat er waarschijnlijk bij startup variables->advanced networking max packet size op 1MB, zet dit naar 16 (of een ander getal wat je graag wilt) en je krijgt geen fouten meer)
*(maar een rare default value trouwens en de foutmelding die je hierbij krijgt is helemaal stom en onbeschrijvend)*

[ Voor 30% gewijzigd door roy-t op 08-06-2008 21:25 ]

~ Mijn prog blog!