[SQL] in WHERE text vergelijken in database

[eatualive]

Hoop dat mijn titel niet al te onduidelijk is. Maar ik heb problemen met de volgende code:

code:

Dim conn, rst

Set conn = CreateObject("ADODB.Connection")
Set rst = CreateObject("ADODB.Recordset")

conn.open "LM_database"

strSQL = "SELECT * FROM t_Machines WHERE Machine_Name=" & Chr(34) & strMachine & Chr(34) & ""

Ik heb een applicatie waarmee ik wat SQL commando's uitvoer naar een ODBC MS ACCESS database. Nu kan ik alle statements in de where functie kwijt zoals datum, tijd nummers etc. Dit werkt zonder problemen.

Nu heb ik een string die ik wil vergelijken met een veld in mijn database. Het veld is een text veld ofwel 255 characters. Als ik dit binnen Microsoft ACCESS uitvoer werkt dit. Nu dat ik het over mijn ODBC uitvoer werkt het niet.

Nu ben ik al een paar uur bezig maar ik kom er maar niet uit. Waarom werkt dit niet? Doe ik iets fout of is er een beperking op de ODBC connectie?

[Boss]

Waarom niet

code:

strSQL = "SELECT * FROM t_Machines WHERE Machine_Name='" & strMachine & "'"

En is de client ook MS Access of ander (vba-achtig) project?

En define 'werkt het niet'. Foutmelding? Ander resultaat dan verwacht?

[ Voor 19% gewijzigd door Boss op 27-06-2012 14:52 ]

[eatualive]

De client is een industrieel programma. Deze maakt gebruik van VBA maar heeft geen error handeling in de zin van dat hij aangeeft wat er fout is. Ik krijg dus alleen een melding dat het fout is. Al weet ik zeker dat de fout in het gedeelte achter WHERE zit.

Dus simpel gezegt gaat de code niet verder dan deze SELECT statement. Als ik het gedeelte achter WHERE verander in Machine_id=5 dan werkt de code wel(integer). Maar goed hij moet zoeken op de machine naam.

Die andere code had ik ook al geprobeerd.

[ Voor 25% gewijzigd door eatualive op 27-06-2012 15:10 ]

[The Eagle]

Als jij strings wilt concatten in SQL moet je voor zover ik weet het piping-teken gebruiken en niet de ampersand. Maar ik ken Access niet goed genoeg om te weten of die dat ook zo wil hebben. Iedere fatsoenlijk DMBS zou zo moeten werken imho
Maar access is dan ook geen DBMS te noemen, al propageert MS al jaren van wel

[Venxir]

Pak de immediate window eens en doe ?strSQL tijdens runtime. Misschien zit je toch met onbedoelde slashes of andere tekens die je moet escapen. Het komt vaak voor dat Acces of SQL ander werkt dan de ADODB library in VBA.

The Eagle schreef op woensdag 27 juni 2012 @ 15:08:
Als jij strings wilt concatten in SQL moet je voor zover ik weet het piping-teken gebruiken en niet de ampersand. Maar ik ken Access niet goed genoeg om te weten of die dat ook zo wil hebben. Iedere fatsoenlijk DMBS zou zo moeten werken imho
Maar access is dan ook geen DBMS te noemen, al propageert MS al jaren van wel

Meestal is het binnen VBA een + of &, ik weet alleen het exacte vershcil niet.

[ Voor 54% gewijzigd door Venxir op 27-06-2012 15:13 ]

[NMe]

The Eagle schreef op woensdag 27 juni 2012 @ 15:08:
Als jij strings wilt concatten in SQL moet je voor zover ik weet het piping-teken gebruiken en niet de ampersand.

Het concatten gebreurt hier in VBA, niet in SQL.

Verder: zelfs als die productieomgeving geen error returnt kun je de VBA op zichzelf toch testen? Maak gewoon ergens een losse file waarin je VBA gebruikt met een uitgeklede case en test of het werkt en wat voor melding je krijgt?

[eatualive]

hmm weet niet hoe het piping teken eruit ziet. Begrijp dat je met dat andere het & teken bedoeld.

Hier een stukje code die wel werkt om jullie een idee te geven hoe het eruit ziet:

code:

See if shift records is already created by other script 
strSQL = "SELECT * FROM t_Shift WHERE Line_id ="&id_Line&" AND ShiftNr="& SmartTags("L" & Line & "_Tags\ShiftNr") & "AND ShiftTime= #"& LTime &" #"  & " AND ShiftDate= #"& Shift_date& "#"
Set rst = conn.Execute(strSQL)

@NME

Nee helaas kan dit niet omdat deze code word geschreven binnen dit industriele programma. Ik ben dus afhankelijk hoe hun de error meldingen weergeven. Het VBA script op zichtzelf wordt goed gekeurd. Alleen als het programma draait kan hij de gegevens niet ophalen omdat er iets fout zit in het Where gedeelte. Dit koppelt hij dan terug als puur 'een' fout.

Als ik dit script vertaal naar Microsoft access VBA dan krijg je dit(Zie laatste Where vergelijking):

code:

'Select information bases on input data
 strSQL = "SELECT t_Data.* " & _
  "From t_Data " & _
  "Where t_Data.[Line]=" & CInt(L_Choice_1.Value) & " AND t_Data.[ShiftNr]= " & CInt(S_Choice_1) & "  AND t_Data.[ShiftDate] = # " & D_Picker_1 & "# AND t_Data.[Machine] = " & Chr(34) & M_Choice_1 & Chr(34) & ""

En dat werkt binnen microsoft access

[ Voor 46% gewijzigd door eatualive op 27-06-2012 15:21 ]

[Remus]

eatualive schreef op woensdag 27 juni 2012 @ 14:45:
Hoop dat mijn titel niet al te onduidelijk is. Maar ik heb problemen met de volgende code:

code:

Dim conn, rst

Set conn = CreateObject("ADODB.Connection")
Set rst = CreateObject("ADODB.Recordset")

conn.open "LM_database"

strSQL = "SELECT * FROM t_Machines WHERE Machine_Name=" & Chr(34) & strMachine & Chr(34) & ""

Als je het al zo wil doen, dan moet je volgens mij een single quote of Chr(39) gebruiken ipv Chr(34) (al kan ik mij vergissen, ik heb alleen SQL Server vanuit VBA gebruikt en dan is het zeker single quote). Maar persoonlijk zou ik ervoor kiezen om een ADODB.Command te gebruiken en te parameteriseren, bijvoorbeeld.

Visual Basic:

Dim conn As New ADODB.Connection
Dim cmd As New ADODB.Command
Dim rs As ADODB.Recordset

conn.open "LM_database"
With cmd
   .ActiveConnection = conn
   .CommandText =  "SELECT * FROM t_Machines WHERE Machine_Name= ?"
   .Parameters.Refresh
   .Parameters(0) = strMachine 
   Set rs = .Execute()
End With

[eatualive]

Ik had Chr(39) ook al getest maar dit werkte helaas ook niet. Ik zal die cmd morgen eens proberen.
Ben alleen niet zo bekend met de parameter gebeuren.

De code is zo toch niet letterlijk? Want op de plek van het vraagteken zou ik toch strMachine willen neerzetten.

Zal morgen wel eens wat opzoeken naar dat paramter verhaal. Misschien dat ik het via die manier werkend kan krijgen. Hoop het wel.

[NMe]

Die code is zo wel letterlijk, dat is juist wat een parameterized query inhoudt.

[eatualive]

K ga het morgen testen. Laat wel weten of het gelukt is.

[Creepy]

En alsnog even een tikje door naar PRG

[eatualive]

Hmm, dat paramteriseren werkt niet. Als ik het letterlijk doe dan accepteerd hij niet de .execute
Heb het ook al zonder het WITH geprobeerd maar dan accepteerd hij 'conn' bij cmd.activeconnection weer niet.
Bij deze laatste geeft hij aan dat hij een set wil zien wat ik niet snap. Aangezien conn ge-set wordt.

[Woy]

eatualive schreef op donderdag 28 juni 2012 @ 08:38:
Hmm, dat paramteriseren werkt niet. Als ik het letterlijk doe dan accepteerd hij niet de .execute
Heb het ook al zonder het WITH geprobeerd maar dan accepteerd hij 'conn' bij cmd.activeconnection weer niet.
Bij deze laatste geeft hij aan dat hij een set wil zien wat ik niet snap. Aangezien conn ge-set wordt.

Je moet natuurlijk ook niet zomaar wat regels gaan verwijderen, als je een foutmelding krijgt. Je moet analyseren wat de fout betekent en dat oplossen.

Als ik het letterlijk doe dan accepteerd hij niet de .execute

Daar kunnen we ( en jij ) natuurlijk niet zo veel meer. Als er een compiler/interpreter fout komt zal deze meer informatie bevatten over de reden dat er iets fout is gegaan. Met die informatie moet je aan de slag gaan.

Maar ik heb het idee dat je sowieso nog niet helemaal goed weet waar je mee bezig bent, en dan is het niet handig als je in een omgeving aan het werk bent waar je geen goede foutmeldingen krijgt. Begin eens gewoon met wat simpele test-scripts die wat database access doen. Als je weet hoe dat werkt kun je het een stuk eenvoudiger toepassen binnen je andere omgeving.

[eatualive]

Dat is het probleem. In access heb ik het werkend, sterker nog ik heb daar wel 50 scripts in staan die werken. Alles ODBC communicatie lukt binnen dit programma behalve dit laatste stukje. En volgens mij gaat het fout met de juiste commando's over ODBC. Ik hoopte dat het een eenvoudig iets was wat ik over het hoofd zag. Want zonder de duidelijke foutmeldingen die ik wel in access zou krijgen is het een lastig verhaal.

Ik werk inderdaad niet elke dag met SQL maar ik ben al heel ver gekomen en nu lijkt zoiets simpels niet te werken wat wel heel fundenmenteel is voor mijn programma.

[ Voor 23% gewijzigd door eatualive op 28-06-2012 09:53 ]

[TallManNL]

Gezien je gebruik van de SmartTags functie gok ik dat je met iets als WinCC (Flexible) bezig bent. Als ik het me goed herinner is dat gewone VBScript die je daar gebruikt en geen VBA.

Bij mijn weten kun je in VBScript gewoon met ON ERROR je errorhandling aangeven.

Visual Basic:

On Error Resume Next ' On error ... resets Err itself, no need to call Err.Clear

' Do some action here
if  Err.Number <> 0  then   
   ' An exception occurred
    Log "Exception:" & vbCrLf &_
        "    Error number: " & Err.Number & vbCrLf &_
        "    Error description: '" & Err.Description & vbCrLf

Dan moet je zelf nog even expirimenteren met je foutlogging en uiteraard welke regel code de fout gooit, maar je zou hiermee meer informatie over de fout moeten kunnen ophalen.

[ Voor 3% gewijzigd door TallManNL op 28-06-2012 10:06 ]

[eatualive]

Ja klopt wincc flexible. Hmm zie dat dit advanced error handeling is zal het eens proberen.
Als eerste een update. Als ik mijn string in een tag stop van het formaat string en dan deze in de where functie zet, dan werk het wel.

Het geeft nog steeds ergens een fout maar ik kan in iedergeval de informatie vergelijken met een juiste output.
Dus code ziet er nu zo uit:

code:

strSQL = "SELECT * FROM t_Machines WHERE Machine_Name = '"& SmartTags("Totals_Db\strMachine") & "'"
Set rst = conn.Execute(strSQL)

Ik kan het alleen niet verklaren omdat het met integers and time en data wel gewoon via een variabelen werkt. In princiepe werkt het, dus bedankt voor het meedenken. Ga nu proberen die fout melding eruit te krijgen.


@edit melding die ik nu nog krijg
Exeption: Error number 3705 Error description 'operation is not allowed when the object is open.

Maar goed denk dat ik dit zelf wel vind. Maar bedankt voor de advanced error handeling. Had eerst alleen systemalarm en type zelf een melding met variabelen erin om te kijken of de informatie correct was.

[ Voor 37% gewijzigd door eatualive op 28-06-2012 10:34 ]

[TallManNL]

In deze code heb je gewoon je single quotes opgenomen ipv via Chr functie op te vragen. Je begon met de foute quote op te nemen " ipv '. Weet je zeker dat je met

code:

strSQL = "SELECT * FROM t_Machines WHERE Machine_Name = '"& strMachine & "'"

er niet al bent?

[NMe]

....en dat er vervolgens in strMachine absoluut géén quote staat (tenzij die ergens escaped wordt)?

[eatualive]

Nu ben ik helemaal de weg kwijt. Nu werkt het wel, en ik weet/dacht zeker dat ik dit getest had.

@laatste foutmelding is ook weg.

Van mijn kan deze gesloten worden. Ben helemaal geholpen!
En bedankt voor die advanced error messaging. Kan ik makkelijker mijn code troubleshooten.

[Remus]

eatualive schreef op donderdag 28 juni 2012 @ 08:38:
Hmm, dat paramteriseren werkt niet. Als ik het letterlijk doe dan accepteerd hij niet de .execute
Heb het ook al zonder het WITH geprobeerd maar dan accepteerd hij 'conn' bij cmd.activeconnection weer niet.
Bij deze laatste geeft hij aan dat hij een set wil zien wat ik niet snap. Aangezien conn ge-set wordt.

Het is heel goed mogelijk dat ipv .ActiveConnection = conn je Set .ActiveConnection = conn moet doen. Mijn post was uit het blote hoofd, al zou het algemene idee gewoon moeten werken (ik heb het nl de afgelopen maanden regelmatig gebruikt).

[TallManNL]

Een toevoeging, je scriptafhandeling gaat met deze instelling errors blijven negeren. Dit kan dus een negatief effect hebben op de afhandeling van je code.
Het is verstandig om On Error Resume Next niet als standaard afhandeling te gebruiken, op specifieke plaatsen kun je op bovenstaande manier wel fouten afvangen en hanteren. Na gebruik kun je met On Error Goto 0 teruggaan naar het standaard gedrag.