[VB.NET/MySQL] parameter in query faalt *

[CaptBiele]

Ik ben bezig met een webmethod, die de tabelnaam als parameter krijgt.

Visual Basic .NET:

 Public Function setXMLFile(ByVal strTable As String) As String
        strTable = Trim(strTable)
        .....

                Dim cnn As New OdbcConnection
                Dim cmd As New OdbcCommand
                Dim strConnection As String = ConfigurationSettings.AppSettings("ConnString")
                Dim da As New OdbcDataAdapter
                Dim ds As New DataSet

                cnn.ConnectionString() = strConnection
                cnn.Open()
                cmd = cnn.CreateCommand
                cmd.CommandText = "SELECT * FROM ?"
                cmd.Parameters.Add(New OdbcParameter("", strTable))

                da.SelectCommand = cmd
                da.Fill(ds, "IQTransData")

                 ......

        Return strReturn

    End Function

Maar nu krijg ik een foutmelding dat mijn SQL statement niet klopt. Het lijkt alsof de parameter niet wordt vervangen door de tabelnaam...
Terwijl ik deze constructie toch al vaker heb gebruikt.

het volgende stukje code wordt wel goed gerund:

Visual Basic .NET:

cmd.CommandText = "SELECT * FROM " & strTable

maar dit wil ik natuurlijk niet.....

[DinX]

Ik ben meer thuis in C# dan in VN.NET ...

Maar wat als je de parameter een naam geeft ?

dus

Visual Basic .NET:

cmd.CommandText = "SELECT * FROM @table";
cmd.Parameters.Add(New OdbcParameter("@table", strTable));

edit: foutje

[ Voor 26% gewijzigd door DinX op 31-05-2004 10:02 ]

[CaptBiele]

DinX schreef op 31 mei 2004 @ 09:37:
Ik ben meer thuis in C# dan in VN.NET ...

Maar wat als je de parameter een naam geeft ?

dus

Visual Basic .NET:

cmd.CommandText = "SELECT * FROM @table";
cmd.Parameters.Add(New OdbcParameter"@table", strTable));

edit: foutje

Het werken met de @ wordt niet ondersteund in MySQL. En ik heb dit principe al vaker gebruikt, dus denk niet dat het daar aan ligt.

[ Voor 10% gewijzigd door CaptBiele op 31-05-2004 09:46 ]

[EfBe]

De parameter wordt at runtime door de sql engine geinterpreteerd, er wordt niets vervangen. Dit houdt dus in dat de sql engine SELECT * FROM variable moet ondersteunen. Bij mijn weten ondersteunt geen enkele database dat.

[CaptBiele]

tja, aan zoiets zat ik ook al aan te denken. Heb je ook een reden waarom dit niet ondersteund wordt misschien?
of een andere manier om tabelnaam als parameter (veilig) te verwerken?

[nescafe]

Een vaste arrays met tabellen opgeven en hiertegen checken?
Ik neem aan dat als je je databasestructuur aanpast je de code toch al moet wijzigen.

[EfBe]

CaptBiele schreef op 31 mei 2004 @ 10:04:
tja, aan zoiets zat ik ook al aan te denken. Heb je ook een reden waarom dit niet ondersteund wordt misschien?
of een andere manier om tabelnaam als parameter (veilig) te verwerken?

Het at runtime vervangen van het ? door de parameter value is precies hetzelfde als het concatenaten van de parameter value in de query.

[CaptBiele]

EfBe schreef op 31 mei 2004 @ 10:08:
[...]

Het at runtime vervangen van het ? door de parameter value is precies hetzelfde als het concatenaten van de parameter value in de query.

Als ik goed begrijp wat je bedoelt dan ben ik het er niet mee eens

Op het moment dat ik parameters gebruik in mijn query controleert het dbms of het wel een geldige parameter is (bijvoorbeeld juiste type?)

Als ik de strTable gewoon concatenate met de SQL query, dan ben ik kwetsbaar voor sql injection attacks.... imo

[whoami]

CaptBiele schreef op 31 mei 2004 @ 10:24:
[...]


Als ik goed begrijp wat je bedoelt dan ben ik het er niet mee eens

Volgens mij bedoelt EfBe dit:

code:

string s = "SELECT * FROM ?".Replace ("?", "Personen");

En dat is wel degelijk hetzelfde als dit (in die zin dat het evenveel risico inhoud):

code:

string theTableName = "Personen";
string s = "SELECT * FROM " + theTableName;

Als jij dynamisch je tabelnaam wilt bepalen, zal je het toch via string concatenation moeten doen.
Als je parameters gebruikt in je query voor waarden in de WHERE clause, zorgt het DBMS er idd voor dat die 'veilig' doorgegeven worden. Echter, een parameter gebruiken voor je tabelnaam wordt niet ondersteund.
Daar zal je dus toch zelf wat controles moeten op uitvoeren.

Als ik de strTable gewoon concatenate met de SQL query, dan ben ik kwetsbaar voor sql injection attacks.... imo

Tja, zelf nagaan of de doorgegeven string wel veilig is lijkt me.

[CaptBiele]

ok, maar voor de volledigheid is dus dit:

Visual Basic .NET:

string s = "SELECT * FROM ?".Replace ("?", "Personen");

niet hetzelfde als:

Visual Basic .NET:

cmd.CommandText = "SELECT * FROM ?"
cmd.Parameters.Add(New OdbcParameter("", strTable))

Als dat klopt dan begrijpen we elkaar

Dan zal ik zelf maar checken op quotes enzo. Denk dat ik wel wat inspiratie op kan doen bij php....

[whoami]

Dat is idd niet hetzelfde, aangezien je 2de voorbeeld niet kan werken. Dat wordt nl. niet ondersteunt, aangezien het geen 'waarde' is die je doorgeeft om te vergelijken met de inhoud v/je DB.

[EfBe]

CaptBiele, je snapt niet wat een command executeren doet. Wat jij opgeeft als het command, DAT wordt uitgevoerd door de sql engine IN de database. Er wordt geen string replace gedaan, de sql wordt geexecuteerd.

Dus als ik doe:
Dim s As String = "SELECT * FROM Table WHERE Foo = @Blaat"
myCommand.CommandTest = s
en ik ga dan een parameter @Blaat toevoegen aan het command, dan zal de sql engine niet @blaat vervangen door de waarde maar de expressie: Foo = value evalueren. Dat is iets heel anders.

Wat dus voor jou betekent: jij wilt SELECT * FROM @table uitvoeren. Dit kan alleen als de sql engine daarwerkelijk een variabele ondersteunt in de FROM clause. Geen enkele database doet dat (is niet te optimaliseren). Dat is wat ik dus zei. Jij veronderstelt dat de sql engine die parameter gaat vervangen door de value van de parameter en dat zou inhouden dat je dan hetzelfde krijgt als dat je de value er direct in plakt, daarom zei ik dat dat hetzelfde zou zijn.

Maar om het kort te houden: wat jij wilt kan niet.

[CaptBiele]

Ah ok. Het is duidelijk dat het anders in elkaar zit als ik d8 inderdaad...

Ik d8 dat het type van de parameter gecontroleerd werd door het dbms (en verwijderen quotes) en dat dan alsnog in het SQL statement geplakt werd.....

kun je misschien iets gedetailleerder uitleggen wat je bedoelt met: foo = value evalueren?