Delphi 2009 MySQL 5.1 (Varbytes)

[mister X630]

Ik heb hier de volgende config:

Windows Vista X64 SP1
MySQL 5.1.30
ODBC 5.1.5 Windows x64 Edition
Delphi 2009

Ik gebruik een TDatabase en een TDatasource/TQuery om gegevens uit de MySQL database te halen.

In deze nieuwe config loop ik tegen het volgende probleem aan:
Als je een query koppelt waar je een berekening loslaat op een veld dan snapt Delphi dit niet meer.
Bijvoorbeeld: Select voornaam, achternaam, CONCAT(voornaam, achternaam) as test from tabel
In delphi kun je dan de kolom "test" niet aan het querycomponent toevoegen. (het veld "test" is dan niet zichtbaar als je rechts klikt op de query en kiest voor "add fields...")

Nog een voorbeeld met een iets andere uitwerking:
Select voornaam, achternaam, AES_DECRYPT(wachtwoord, "encryptiekey") as wachtwoord from tabel
In delphi kun je de kolom wachtwoord dan wel toevoegen aan het querycomponent, maar dan worden alle waarden terug gegeven als "VarBytes".

Je verwacht dat je dit dan kan oplossen met een CAST:
Select voornaam, achternaam, CAST(AES_DECRYPT(wachtwoord, "encryptiekey") AS CHAR(30)) as wachtwoord from tabel
Om een eventueel verkeerde waarde weer terug te geven als een string, maar dan wordt de terug gegeven waarde "unknown" en kun je de kolom weer niet toevoegen aan je component.

Wanneer je de query uitvoerd in bijvoorbeeld de MySQL QueryBrowser krijg je wel netjes de juiste uitvoer te zien en het werkt ook prima met Delphi 2006 op Windows 32bits met MySQL ODBC 3.51.

Ik hoop dat het een beetje duidelijk is wat ik bedoel, beetje lastig uit te leggen zonder het te zien.
Iemand enige idee wat hier mis gaat?

[ Voor 5% gewijzigd door mister X630 op 27-01-2009 14:02 ]

[Niemand_Anders]

Hoe gaat delphi met de velden om als je de query in een view plaatst?

Ik heb al sinds 1997 niet meer met delphi gewerkt en rond 2001 even kort in Kylix (Delphi voor Linux). Maar delphi analyseert toch niet zelf de query? Het lijkt mij dat deze de query gewoon afvuurt op de database en vervolgens het schema van de response gebruikt om te bepalen van welke datatype een veld is.

Een ander iets wat je kunt proberen is ipv char(30) varchar(30) te gebruiken. Het eerste resulteerde waarschijnlijk in char[30] en het tweede string[30]..

[mister X630]

Niemand_Anders schreef op dinsdag 27 januari 2009 @ 14:17:
Hoe gaat delphi met de velden om als je de query in een view plaatst?

Ik heb al sinds 1997 niet meer met delphi gewerkt en rond 2001 even kort in Kylix (Delphi voor Linux). Maar delphi analyseert toch niet zelf de query? Het lijkt mij dat deze de query gewoon afvuurt op de database en vervolgens het schema van de response gebruikt om te bepalen van welke datatype een veld is.

Een ander iets wat je kunt proberen is ipv char(30) varchar(30) te gebruiken. Het eerste resulteerde waarschijnlijk in char\[30] en het tweede string\[30]..

Bedankt voor je reactie:
Dat had ik ook al geprobeerd, maar varchar kun je niet gebruiken in een cast.
zie hier: http://bugs.mysql.com/bug.php?id=34564

En diezelfde syntax-error krijg je nog steeds in de huidige versie.

[update1]
Ik zal het eens met een view proberen...
(maar dat is eigenlijk niet wat ik wil... want dan moet ik mijn encryptie-sleutel ook in de view zetten, of zeg ik iets geks?)
[/update1]

[update2]
Zojuist geprobeerd met een view, maar dan blijft het probleem exact hetzelfde. De terug gegeven waardes van een decrypted veld worden dan varbytes in Delphi. En met een CAST er omheen wordt het "unknown" en verdwijnen de velden.
[/update2]

[ Voor 23% gewijzigd door mister X630 op 27-01-2009 14:41 ]

[Niemand_Anders]

@update 1: Of je encryptie sleutel zich nou in de query (en dus zelfs de client) of de view zich bevind maakt toch niet zoveel uit? Tenzij elke client een eigen unieke encryptiekey gebruikt, is de view zelf veiliger. Jouw encryptiekey zal echter als configuratie waarde of als constante in je programma bekend zijn. Met een hex editor kun je vrij eenvoudig scannen (kijk bijvoorbeeld maar eens naar het Linux 'strings' commando). Als je key in de view staat, moet een 'hacker' zich eerst toegang tot je database server verschaffen.

En als je dezelfde query is Delphi 2006 gebruik gaat alles wel goed? In dat geval zou je kunnen denk aan een workaround waarbij je middels Delphi 2006 het 'data' component schrijft en deze vervolgens gebruikt in Delphi 2009. Niet optimaal, maar wel opvallend als dat zou werken..

Een andere oplossing is het gebruik van ADO.NET drivers in Delphi 2009. Volgens mij is die support er bij Delphi 2006 bij gekomen. Ik heb vroeger nooit lekker met ODBC kunnen werken, maar Borland zal vast ODBC support de laatste 10 jaar wel verbeterd hebben, toch?!

[The Fox NL]

mister X630 schreef op dinsdag 27 januari 2009 @ 14:00:
Wanneer je de query uitvoerd in bijvoorbeeld de MySQL QueryBrowser krijg je wel netjes de juiste uitvoer te zien en het werkt ook prima met Delphi 2006 op Windows 32bits met MySQL ODBC 3.51.

Ik hoop dat het een beetje duidelijk is wat ik bedoel, beetje lastig uit te leggen zonder het te zien.
Iemand enige idee wat hier mis gaat?

Delphi 2009 is de eerste Delphi met native Unicode support, misschien dat het daarom met een oude Delphi versie wel werkt. Zijn de drivers wel geschikt voor Unicode?

Probeer anders eens de MySQL database te benaderen via dbexpress, dat is de manier waarop in nieuwe Delphi versies databases benaderd moeten worden. BDE e.d. is afgeschreven. Hoe je het precies doet weet ik niet, zelf werk ik daar niet zoveel mee. Google er maar eens op.

[Niemand_Anders]

Heeft MySQL toevallig geen support voor nvarchar data types?

En anders moet je even contact opnemen bij Borland want Delphi claimt MySQL support te hebben via Borland Data Providers.

[mister X630]

Niemand_Anders schreef op dinsdag 27 januari 2009 @ 16:44:
@update 1: Of je encryptie sleutel zich nou in de query (en dus zelfs de client) of de view zich bevind maakt toch niet zoveel uit? Tenzij elke client een eigen unieke encryptiekey gebruikt, is de view zelf veiliger. Jouw encryptiekey zal echter als configuratie waarde of als constante in je programma bekend zijn. Met een hex editor kun je vrij eenvoudig scannen (kijk bijvoorbeeld maar eens naar het Linux 'strings' commando). Als je key in de view staat, moet een 'hacker' zich eerst toegang tot je database server verschaffen.

Daar heb je eigenlijk helemaal gelijk in!

En als je dezelfde query is Delphi 2006 gebruik gaat alles wel goed? In dat geval zou je kunnen denk aan een workaround waarbij je middels Delphi 2006 het 'data' component schrijft en deze vervolgens gebruikt in Delphi 2009. Niet optimaal, maar wel opvallend als dat zou werken..

Dat gaat absoluut goed, want ik ben juist bezig met een conversie van werkende projecten uit versie 2006 naar 2009. Maar om nou componenten uit de ene Delphi over te zetten in de nieuwere versie, dat gaat mij een stapje te ver. Dat moet vast niet nodig zijn. Ik doe helemaal niks bijzonders in mijn opbouw. Zijn vrij basic apps, dus ik heb liever een oplossing i.p.v. een workaround.

Een andere oplossing is het gebruik van ADO.NET drivers in Delphi 2009. Volgens mij is die support er bij Delphi 2006 bij gekomen. Ik heb vroeger nooit lekker met ODBC kunnen werken, maar Borland zal vast ODBC support de laatste 10 jaar wel verbeterd hebben, toch?!

Ja, daar was ik al naar aan het kijken. Dat leek mij inderdaad een oplossing, omdat dat gewoon veel nieuwere techiek is dan ODBC natuurlijk. Maar ik kan zo 1,2,3 niet uitvogelen of vinden hoe ik op een vergelijkbare manier een ADO-connectie leg naar mijn database. Heb je misschien tips over? Nu gebruik ik dus een TDatabase / TDatasource / TQuery.

[ Voor 10% gewijzigd door mister X630 op 28-01-2009 08:53 ]

[Niemand_Anders]

mister X630 schreef op woensdag 28 januari 2009 @ 08:50:
"Een andere oplossing is het gebruik van ADO.NET drivers in Delphi 2009. Volgens mij is die support er bij Delphi 2006 bij gekomen. Ik heb vroeger nooit lekker met ODBC kunnen werken, maar Borland zal vast ODBC support de laatste 10 jaar wel verbeterd hebben, toch?!"

Ja, daar was ik al naar aan het kijken. Dat leek mij inderdaad een oplossing, omdat dat gewoon veel nieuwere techiek is dan ODBC natuurlijk. Maar ik kan zo 1,2,3 niet uitvogelen of vinden hoe ik op een vergelijkbare manier een ADO-connectie leg naar mijn database. Heb je misschien tips over? Nu gebruik ik dus een TDatabase / TDatasource / TQuery.

Een snelle zoektoch op Google leverde dit voorbeeld op: http://www.codebase.com/support/kb/?article=C01022.
Het voorbeeld gaat uit van de CodeBase database, maar alle ADO.NET providers werken op dezelfde manier. Uit eigen ervaring kan ik zeggen dat de .NET Connectors van MySQL erg goed zijn.

[mister X630]

Dank je wel Niemand _Anders

Ik had het alleen al voor elkaar. Zojuist heb ik het getest met een ADOConnection en ADOquery componenten, dat werkt op zich prima, maar lost het probleem niet op.
Ik krijg op precies dezelfde velden errors: "Data provider or other service returned an E_FAIL status"

Ik krijg het gevoel dat ik echt terug moet naar 32-bit windows zodat ik weer met ODBC 3.51 kan gaan werken. (de 64-bit variant van ODBC 3.51 is er ook, maar geeft weer een hele andere error i.c.m. Delphi 2009 ook al werken de ODBC koppelingen zelf wel goed)

Ik zal jullie de exact query geven, er staat niks bijzonders in, dus kan wel: (heb alleen de key even verwijderd)

code:

SELECT
  g.gebruiker_ID,
  AES_DECRYPT(g.voornaam,"<key>") AS voornaam, 
  AES_DECRYPT(g.achternaam,"<key>") AS achternaam, 
  g.afdeling_ID, 
  a.afdeling, 
  g.aanmaakdatum, 
  g.archief
FROM 
  gebruikers g
LEFT OUTER JOIN afdelingen a ON g.afdeling_ID = a.afdeling_ID

Zoals jullie zien een hele eenvoudige query, niks bijzonders.
Het gaat dus mis op de 2e en 3e regel. Als je deze twee weg laat gaat het goed. Als je ze zonder een decrypt ophaalt gaat het goed. En als je er bijvoorbeeld een concat(voornaam, achternaam) van maakt gaat het ook mis. (ook als je er nog een CAST() omheen zet)

[ Voor 45% gewijzigd door mister X630 op 28-01-2009 10:53 ]