[Delphi / SQLBase] Foutmelding Command not properly ended

Pagina: 1
Acties:

  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Topicstarter
Huidige situatie
Ik moet een applicatie maken die nogal wat gegevens uit een database van een ander pakket trekt en daar vervolgens mee gaat werken. Mijn Delphi applicatie kan de database netjes aanspreken via de bijgeleverde ODBC-koppeling en het uitvoeren van simpele queries gaat correct.

Probleem
Wanneer ik een 'ingewikkelde query' ga gebruiken, krijg ik foutmeldingen. Bijvoorbeeld: wanneer ik de joins probeer te groeperen door er haakjes omheen te zetten, krijg ik een invalid tablename. Wanneer ik mijn 'ingewikkelde query' zonder haakjes of iets anders in een TADOQuery kinkel, krijg ik de melding Command not properly ended.

Google!
Google rules, maar laat me, in combinatie met de naam Merant (provider), in de steek wat betreft deze vraag. De foutcode die ik bij de Command-fout krijg (00901) helpt me hier helaas niets bij.

Wat wil je nou?
Een oplossing ;) Ik heb de help (voor zover meegeleverd) over de SQLBase server al bekeken, maar daar staat niks in over terminators voor de queries. Ik heb ook de puntkomma geprobeerd als terminator, maar omdat simpele queries wel goed worden uitgevoerd, snap ik het probleem niet helemaal :?

Oftewel:
zijn er mensen in de buurt die enig idee hebben waar dit probleem vandaan komt?

X-tra info
De query die ik gebruik is, enigszins versimpeld in verband met de ruimte, de volgende:
SQL:
1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT 
   SUBADRES, FACTUUROPDRACHT, CDDEBITEUR, OPDRACHTDATUM, 
   REFERENTIE, CDARTIKEL, OMSCHR, AANTALBESTELD, VOORRAAD 
FROM ARTIKEL 

RIGHT JOIN FACTOPDRACHTREGEL 
  RIGHT JOIN FACTUREEROPDRACHT 

ON FACTOPDRACHTREGEL.FACTUUROPDRACHT = FACTUREEROPDRACHT.FACTUUROPDRACHT 
  ON FACTOPDRACHTREGEL.CDARTIKEL = ARTIKEL.CDARTIKEL 

LEFT JOIN VOORRADEN ON 
  VOORRADEN.CDARTIKEL = ARTIKEL.CDARTIKEL


De versie van Delphi is 7 en van de MDAC en de Jet drivers heb ik de laatste versies geïnstalleerd (respectievelijk 2.8 en 4.0 SP 8). Verder werkt de query die ik heb gemaakt (de volledige!) wel correct wanneer ik de tabellen importeer in een Access-database.

Ik vermoed dus dat het ergens in een kleinigheid zit die in de SQLBase-database anders werkt dan in een SQL server database, of een Access database...

iemand?

My personal website


Verwijderd

Zet er eens een ; achter

  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Topicstarter
Ik heb ook de puntkomma geprobeerd als terminator, maar omdat simpele queries wel goed worden uitgevoerd, snap ik het probleem niet helemaal
;)

My personal website


  • SavageNL
  • Registratie: November 2001
  • Laatst online: 27-05 08:12
Lukt de query wel met een ander programma? Misschien ipv ODBC eens een verbinding proberen te leggen met JET 3.5 of 4...

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Is die rare nesting van die rightjoins zo wel geldig ?
En probeer dat iig es met een stel haakjes voor de dbms te verduidelijken?

Verder kan je de terminator 'GO' nog proberen.

  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Topicstarter
Een verbinding leggen met een SQLBase server met Jet 3.5 of 4? Dat gaat ook niet heel erg lukken...

Het betreft hier de database van een administratief pakket, dus deze is ernstig beschermd. Ik mocht al blij zijn met het ODBC-wachtwoord (volgens de mevrouw bij de leverancier van de software ;)). Uiteindelijk kan ik dus de tabellen etc. goed bekijken, en het uitvoeren van een SELECT * FROM ARTIKELEN query is ook geen enkel probleem, maar bij 'ingewikkelde queries' gaat hij moeilijk doen.

Edit:
@SavageNL: ja, in een andere interface werkt de query correct.

@ACM: die nesting van die joins werkt met de tabellen geimporteerd in een access database wel. Zoals ik ook al in mijn openingspost had staan. Net als dat ik er in had staan dat haakjes voor de melding unknown table name zorgen ;)

De GO als terminator heb ik net geprobeerd en wil helaas niet de oplossing bieden. :'(

[ Voor 34% gewijzigd door OZ-Gump op 04-12-2003 20:08 ]

My personal website


  • SavageNL
  • Registratie: November 2001
  • Laatst online: 27-05 08:12
Nog iets trouwens, 'invalid table' kan er ook op duiden dat je execSQL gebruikt ipv open. Maar welke componenten gebruik je om de connectie te maken?

<edit>
Sorry, dacht dat het over een SQL-server ging :z
</edit>

[ Voor 23% gewijzigd door SavageNL op 04-12-2003 20:08 ]


  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Topicstarter
SavageNL schreef op 04 december 2003 @ 20:06:
Nog iets trouwens, 'invalid table' kan er ook op duiden dat je execSQL gebruikt ipv open. Maar welke componenten gebruik je om de connectie te maken?
De melding waar het nu dus om gaat is degene die me vertelt dat ik mijn command niet netjes heb beeindigd. Ik gebruik binnen Delphi de standaard ADO componenten om verbinding te maken met de SQLBase server. (ADOConnection en ADOQuery op dit moment).

[ Voor 3% gewijzigd door OZ-Gump op 04-12-2003 20:10 ]

My personal website


  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

OZ-Gump schreef op 04 december 2003 @ 20:03:
@ACM: die nesting van die joins werkt met de tabellen geimporteerd in een access database wel. Zoals ik ook al in mijn openingspost had staan. Net als dat ik er in had staan dat haakjes voor de melding unknown table name zorgen ;)
Niet elke database implementeert alles even goed, dus als het in access wel werkt is dat niet perse een garantie voor sqlbase.

Maar bovenstaande query werkt al niet?
Probeer hem es langzaam op te bouwen naar wat je nu hebt om te achterhalen waar SQLbase de mist in gaat?
Dus eerst de left en right joins weglaten, dan 1 right join erbij, dan de 2e erin, etc

[ Voor 4% gewijzigd door ACM op 04-12-2003 20:24 ]


  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Topicstarter
Dat rustig aan opbouwen was inderdaad ook mijn eerstvolgende plan, maar omdat ik tijdens mijn vorige post nog op mijn werk zat, ben ik uiteindelijk toch maar naar huis gegaan ;)
Morgenvroeg meteen maar eens uitproberen. I'll keep you posted

My personal website


  • Just_a_Gamer
  • Registratie: November 2001
  • Laatst online: 15:42
misschien moet je dit eens proberen:

code:
1
2
3
4
5
6
7
8
9
10
11
SELECT 
   SUBADRES, FACTUUROPDRACHT, CDDEBITEUR, OPDRACHTDATUM, 
   REFERENTIE, CDARTIKEL, OMSCHR, AANTALBESTELD, VOORRAAD 
FROM ARTIKEL AS AR

RIGHT JOIN FACTOPDRACHTREGEL AS FR
  ON FR.CDARTIKEL = AR.CDARTIKEL 
  RIGHT JOIN FACTUREEROPDRACHT AS FO
    ON FR.FACTUUROPDRACHT = FO.FACTUUROPDRACHT 
    LEFT JOIN VOORRADEN AS VR
    ON VR.CDARTIKEL = AR.CDARTIKEL


Misschien omdat ie de volgorde van die ON's niet goed vindt :)

[wijsneus-mode on]
GO is btw geen T-SQL. Go geeft alleen maar aan dat het de einde is van een batch en is alleen bruikbaar binnen Query Analyzer :)
[/wijsneus-mode off]

[ Voor 16% gewijzigd door Just_a_Gamer op 04-12-2003 23:57 ]


  • OZ-Gump
  • Registratie: November 2002
  • Laatst online: 14-05-2024

OZ-Gump

terug van weggeweest

Topicstarter
Zo... ik ben al een stukje verder. Het blijkt nu dat een outer join omgeven dient te worden door {oj }. Dat wil dus zeggen dat je join er uitziet als
SQL:
1
... from {oj TabelA OUTER JOIN TabelB on TabelA.x = TabelB.x}

Nou alleen nog meerdere joins bij elkaar zien te krijgen..... Het lijkt er namelijk op dat de ODBC-driver dat niet gaat pikken, maar we zullen zien.

My personal website

Pagina: 1