[Delphi/MSSQL] MSSQL slikt query niet i.c.m. ADO componenten

[zwik]

Hoi,

Ik heb een stukje code gemaakt die een query stuurt naar een MSSQL database. De database zou vervolgens een waarde terug moeten geven aan het ADO component die ik vervolgens op het scherm kan weergeven met behulp van een ADOTable. De query bouw ik op met behulp van een ADOQuery.

De SQL query maak ik dynamisch aan en klopt want deze heb ik heb ik met behulp van een watch gevangen. De SQL code heb ik vervolgens op de database server getest en geeft de waarde gewoon terug.

Een voorbeeld van de SQL is bijvoorbeeld:

SQL:

SELECT SUM(tijdsduur) AS tijd FROM service WHERE (datum LIKE '%%%%-%%-%%')

Hieronder zal ik het stukje code plaatsen wat niet helemaal goed gaat.

Delphi:

ADOQuery1.ConnectionString := ADOTable2.ConnectionString;
with ADOQuery1 do
begin
  SQL.Clear;
  SQL.Text := 'SELECT SUM(tijdsduur) AS totaal ' +
              'FROM ' + Trim( DBLookupComboBox_Tabel.Text ) + ' ' +
              'WHERE (datum LIKE ' + '''%%%%-%%-%%''' + ')';
  try
    ExecSQL;
    ADOTable2.Close;
    ADOTable2.Open;
    ADOTable2.Insert;
  except on
    e:Exception do
      ShowMessage( 'Het zoeken ging niet goed.' );
  end;
end;

Wat ik ook geprobeerd heb is om een ADOCommand te gebruiken, maar daar gebeurd precies hetzelfde mee.

De tabel bestaat uit meerdere colommen. De SQL code geeft 1 colom met 1 waarde terug. Ik wil dus dat in de ADOTable alleen die colom (totaal) met de waarde die ik in de SQL code laat optellen.

Hoe los ik dit op?

Mocht er behoefte zijn aan meer informatie wil ik deze natuurlijk graag posten.

[whoami]

Een LIKE kan je niet op een datumveld gebruiken. LIKE kan je enkel op alfanumerieke columns gebruiken.
Voor zover ik weet kent SQL Server ook geen TRIM functie, maar wel een LTRIM en RTRIM.
Beter lezen, je gebruikt geen trim in sql server.

Welke fout krijg je precies terug? Toon eens de fout die gegooid wordt, ipv ze op te vangen en te vervangen door een custom error.

Op welke regel krijg je die fout trouwens? Ik vermoed dat je ze krijgt bij de 'Insert'. Je recordset zal nl. niet 'requestlive' zijn.

[ Voor 82% gewijzigd door whoami op 07-04-2004 10:23 ]

[zwik]

Ohja. In mijn geval is het datum veld wel alfanumeriek. Vraag me niet waarom .

Ik zou er dus bijvoorbeeld ook een letter in kunnen zetten waardoor een LIKE wel degelijk mogelijk is.

Ik krijg helemaal geen fout melding(en). Hij accepteert de SQL gewoon en loopt dus gewoon het try stukje af waardoor hij niet bij het except stukje komt.

[ Voor 30% gewijzigd door zwik op 07-04-2004 10:26 ]

[whoami]

check m'n edit.

[zwik]

Zie edit .

Ik kan het stukje waar de ADOTable geclosed etc. ook gewoon weg laten en ik allerlei verschillende volgordes neerzetten, hij krijgt gewoon geen results terug lijkt wel.

[whoami]

Als je gegevens ophaalt, moet je ook geen ExecSQL doen, maar de Open method gebruiken.
(zie de Delphi help voor meer info; Open wordt gebruikt voor queries die een recordset teruggeven, execsql wordt gebruikt voor inserts/updates/deletes).

[zwik]

Hmm je hebt gelijk. Helaas werkt het nog steeds niet.

[AdLentis]

Volgens mij is dat statement '%%%%-%%-%%' ook niet echt wat je bedoelt, want % staat voor een willekeurig aantal tekens, en mag zelfs leeg zijn. een '_' staat voor 1 teken.

Ik weet het zo niet zeker, maar '%%' staat volgens mij voor 1 letterlijke '%'.

[ Voor 34% gewijzigd door AdLentis op 07-04-2004 10:45 ]

[whoami]

Wat is niet werken.
Heb je je exception handling al weggehaald? Heb je al gedebugged, en weet je al op welke regel je die fout krijgt? Welke foutmelding krijg je etc.....

[Johnny Goodbye]

Als de sql laat uitvoeren in een adoQuery dan krijg je het ook daarin terug en niet in je adotable. en inderdaad je moet open gebruiken ipv execsql.

voor resultaat moet je gewoon een datasource koppelen aan de adoquery en de dbgrid o.i.d koppelen aan deze datasource

[whoami]

Johnny Goodbye schreef op 07 april 2004 @ 10:43:
Als de sql laat uitvoeren in een adoQuery dan krijg je het ook daarin terug en niet in je adotable. en inderdaad je moet open gebruiken ipv execsql.

True, had ik nog niet eens gezien.
Dat van die wildcards (% en _) is ook waar, maar het is gewoon ranzig om een datumveld in een (var)char te stoppen.

[zwik]

OK, ik heb de % tekens vervangen door _ tekens.

Ik krijg geen foutmelding terug, ook niet als ik de custom error weghaal. Wanneer ik ga debuggen loopt het programma gewoon goed en doorloopt gewoon alle code. Juist omdat ik geen errors/warnings/runtime errors krijg snap ik het niet .

Ik weet dat ik de datasource moet koppelen, dat werkt gewoon. Ergens anders in het programma heb ik een ORDER BY functie zitten die op exact dezelfde manier werkt en deze werkt wel. Deze heb ik ook met een ADOQuery gebouwd en geeft het gewenste resultaat in een DBGrid. Nu probeer ik hetzelfde met een SUM maar deze geeft geen resultaat in het DBGrid terwijl de datasource hetzelfde is.

[Johnny Goodbye]

als je query uitvoert zonder de where (datum like ....... . Gaat dat wel goed? Dan mankeeert er iets aan je where clause. Gaat dit niet goed dan moet er iets met koppelingen tussen dataset - datasource - dbgrid niet kloppen

[whoami]

Zijn er records in die tabel waarvoor 'tijdsduur' NULL is ?
Zoja, dan kan het zijn dat het daardoor is dat het met die SUM niet werkt:
3 + NULL + 2 is nl. NULL.

Pas je query eens aan, zodat hij er zo uitziet:

code:

select sum(isnull(tijdsduur, 0))
from ...

[AdLentis]

Doe eens een showmessage met een recordcount ofzo, kan je zien of er sowieso wel iets van resultaat uitkomt. Misschien filtert die where clause wel alles d'ruit.

[zwik]

Nieuwe ronde nieuwe kansen .

Ik heb het where stukje weggelaten, wederom krijg ik geen resultaten. Vervolgens gekeken naar de koppeling van ADOQuery, ADOTable en het DBGrid. Ziet er gewoon goed uit.

We gaan testen met een eerder gebruikte SQL query bijvoorbeeld met een ORDER BY die ik eerder gebruikt heb.

Onderstaande code

Delphi:

ADOQuery1.ConnectionString := ADOTable2.ConnectionString;
with ADOQuery1 do
begin
  SQL.Clear;
  SQL.Text := 'SELECT SUM(tijdsduur) AS totaal ' +
              'FROM ' + Trim( DBLookupComboBox_Tabel.Text ) + ' ' +
              'WHERE (datum LIKE ' + '''____-__-__''' + ')}';
  try
//        ExecSQL;
    Open;
    ADOTable2.Close;
    ADOTable2.Open;
    ADOTable2.Insert;
  except on
    e:Exception do
      ShowMessage( 'Het zoeken ging niet goed.' );
  end;
end;

heb ik ervangen voor deze:

Delphi:

ADOQuery1.ConnectionString := ADOTable2.ConnectionString;
with ADOQuery1 do
begin
  SQL.Clear;
  SQL.Text := 'SELECT * FROM ' + Trim( DBLookupComboBox_Tabel.Text ) +
              ' ORDER BY begintijd DESC, datum DESC';
  try
//        ExecSQL;
    Open;
    ADOTable2.Close;
    ADOTable2.Open;
    ADOTable2.Insert;
  except on
    e:Exception do
      ShowMessage( 'Het zoeken ging niet goed.' );
  end;
end;

Deze code voert ie wel goed uit en geeft goede results terug. Zelfs als ik begintijd en datum bij het ORDER BY stukje omwissel krijg ik andere resultaten. De koppeling tussen ADOQuery, ADOTable en DBGrid is dus ok.

Wanneer ik het vervolgens weer terug verander naar wat ie zou moeten doen krijg ik geen results terug. Een rare situatie .

[whoami]

Het zal met NULL value's te maken hebben.

[cameodski]

Heb je al eens met de profiler (tool die bij MSSQL zit) gekeken welke query er precies uitgevoerd wordt.
En vervolgens gekeken wat de query in de Query Analyzer voor resultaat teruggeeft.
Als dat gewoon werkt, weet je in ieder geval zeker dat je query goed is.

[zwik]

whoami schreef op 07 april 2004 @ 11:34:
Het zal met NULL value's te maken hebben.

Het tijdsduur veld moet ingevuld worden net zoals alle andere velden. In de hele tabel zijn geen NULL waardes te vinden.

cameodski schreef op 07 april 2004 @ 11:42:
Heb je al eens met de profiler (tool die bij MSSQL zit) gekeken welke query er precies uitgevoerd wordt.
En vervolgens gekeken wat de query in de Query Analyzer voor resultaat teruggeeft.
Als dat gewoon werkt, weet je in ieder geval zeker dat je query goed is.

Ja ik heb de queries tijdens het debuggen met behulp van een watch eruit gevist en deze vervolgens in handmatig op de MSSQL server uitgevoerd. Hiermee krijg ik wel gewoon results.

Ik heb nogmaals gekeken met de profiler en deze vervolgens getest in de analyzer, maar ze blijven gewoon results geven .

AdLentis schreef op 07 april 2004 @ 11:22:
Doe eens een showmessage met een recordcount ofzo, kan je zien of er sowieso wel iets van resultaat uitkomt. Misschien filtert die where clause wel alles d'ruit.

Dit heb ik ook geprobeerd en geeft gewoon het aantal records terug.

[ Voor 105% gewijzigd door zwik op 07-04-2004 11:52 ]

[Johnny Goodbye]

heb je in de dbgrid kolommen gedefinieerd? zoja, gooi deze weg. het kan zijn dat daar geen kolom totaal in voorkomt

[zwik]

Nope, het enige wat ik aan het DBGrid veranderd heb is de DataSource omdat die anders niet werkt .

[zwik]

*schopje*

Ondertussen heb ik een nieuw test projectje opgezet om te kijken of het dan wel werkt (1 sum waarde teruggeven en die in 1 row/column neerzetten). Ik heb gekeken met de Profiler en Query Analizer om te controleren of de query klopt. Beide geven aan dat de query klopt en geven netjes de sum waarde terug.

Ik zit met de handen in het haar. Is het eigenlijk wel mogelijk ADOQuery dit te doen? INSERTS en SORTS werken er wel gewoon namelijk. De links met DataSource en ADOTable liggen gewoon goed.

[zwik]

Ok, ik heb ondertussen wat ontdekt. Misschien kunnen jullie er wat mee. Zoals ik al gezegd heb krijg ik met de Profiler en de Query Analizer gewoon results van de sum query. Met het volgende stukje code krijg ik een error message omdat ik een NULL waarde terugkrijg.

Delphi:

ShowMessage( ADOQuery1.FieldByName( 'totaal' ).Value );

Dit stukje code heb ik geplaatst na de query (duh) en levert de volgende foutmelding op wanneer ik het programma run:

Project bla.exe raised exception class EVariantTypeCastError with message 'Could not convert variant of type (Null) into type (String)'. Process stopped. Use Step or Run to continue.

Ok fijn. Toen heb ik er het volgende van gemaakt:

Delphi:

ShowMessage( ADOQuery1.FieldByName( 'totaal' ).AsString );

Dit stukje geeft dus gewoon een lege messagebox. Ik zal hieronder nog het stukje code plakken zoals het er nu uitziet om het overzichtelijk te houden.

Delphi:

begin
  ADOQuery1.ConnectionString := ADOTable2.ConnectionString;
  with ADOQuery1 do
  begin
    SQL.Clear;
    SQL.Text := 'SELECT SUM(tijdsduur) AS totaal ' +
                'FROM ' + Trim( DBLookupComboBox_Tabel.Text ) + ' ' +
                'WHERE (datum LIKE ' + '''____-__-__''' + ')';
    try
      Open;
      ADOTable2.Close;
      ADOTable2.Open;
      ADOTable2.Insert;
      ShowMessage( ADOQuery1.FieldByName( 'totaal' ).AsString );
    except on
      e:Exception do
        ShowMessage( 'Het zoeken ging niet goed.' );
    end;
  end;
end;

Het gaat dus fout op de regel met de ShowMessage. En geeft dus duidelijk een NULL waarde terug terwijl de Profiler en Query Analizer keurig een normale waarde teruggeven.

[ Voor 7% gewijzigd door zwik op 13-04-2004 13:09 ]

[Just_a_Gamer]

Doe eens een showmessage(Trim( DBLookupComboBox_Tabel.Text )); voor SQL.Text := <je sql>

Misschien DBLookupCombox_Tabel.Text iets anders weergeeft dan je denkt.

[zwik]

Just_a_Gamer schreef op 13 april 2004 @ 20:54:
Doe eens een showmessage(Trim( DBLookupComboBox_Tabel.Text )); voor SQL.Text := <je sql>

Misschien DBLookupCombox_Tabel.Text iets anders weergeeft dan je denkt.

Deze geeft gewoon de tabelnaam terug. Dat klopt ook want dat heb ik ook opgevangen met de Profiler en Query Analizer.

[cameodski]

Kun je de ShowMessage eens voor je ADOTable2 statements zetten, dus direct na het openen van je query.
Of had je dat al geprobeerd?

[zwik]

Ja dat heb ik ook al geprobeerd . Ondertussen heb ik die ShowMessage dingetjes op alle plekken gehad. Steeds hetzelfde resultaat. Niks dus .

[Just_a_Gamer]

Hmm bij mij thuis werkt ie perfect (Delphi 7 + ms sql 7)

-Als je die like weghaalt dan krijg je wel resultaten?
-Laat eens de sql statement zien die je in de Query Analyzer tik.
-Hoe zien de waardes van datum uit in de database?
-Wat wil je met het LIKE stukje bereiken? Misschien kunnen we een workaround bedenken. Btw zoals iemand al zei Datums in (Var)Char zetten is ranzig.

[zwik]

Just_a_Gamer schreef op 14 april 2004 @ 20:39:
Hmm bij mij thuis werkt ie perfect (Delphi 7 + ms sql 7)

-Als je die like weghaalt dan krijg je wel resultaten?
-Laat eens de sql statement zien die je in de Query Analyzer tik.
-Hoe zien de waardes van datum uit in de database?
-Wat wil je met het LIKE stukje bereiken? Misschien kunnen we een workaround bedenken. Btw zoals iemand al zei Datums in (Var)Char zetten is ranzig.

- Wanneer ik de like weghaal krijg ik geen resultaten en lijkt geen enkel effect te hebben op de uitvoer.
- het SQL statement copieer ik regelrecht uit de Profiler in de Query Analizer. En kan er dus alsvolgt uitzien:

SQL:

SELECT SUM(tijdsduur) AS totaal FROM service WHERE (datum LIKE '____-__-__')

- Een datum ziet er als volgt uit: jaar-maand-dag. Voorbeeld: 2004-04-26.
- Met het LIKE stukje wil ik later een sommatie kunnen maken per jaar/maand/dag en combinaties daarvan.

[whoami]

Als het nog mogelijk is zou ik toch dat varchar veld naar een datetime veld omzetten. Dat is veel beter, je kan datums vergelijken, en je kan ook sommaties maken per jaar / maand / dag.

[Delphi32]

Mja ik ken dit gedrag ook alleen van situaties waarin de sum leeg is (NULL) omdat de set waarover gesommeerd wordt, leeg is (geen records -> geen optelling -> = NULL), of een null value in het gesommeerde veld bevat. Je hebt zelf al uitgesloten dat er NULL values in je veld Tijdsduur zaten (toch?).
Dus ofwel je set wordt door de WHERE leeggegooid ofwel je had een resultaat mogen verwachten. Volgens jou levert de query met WHERE in Query Analyzer een waarde op, dus die sluiten we ook uit.

Blijft over: je had een resultaat mogen verwachten maar je krijgt het niet. Nou, ga maar versienummers controleren dan Welke versie MSSQL? Welke versie ADO (niet geheel onbelangrijk)? Welke versie Delphi? Eventuele patches geïnstalleerd?

[zwik]

Ok, ik heb de tabel gecopieert naar een test tabel en het veld verandert naar een datetime veld.

Ook heb ik de code lichtelijk aangepast zodat MSSQL het formaat snapt (uit de helpfile van MSSQL gehaald). Het stukje code ziet er nu als volgt uit:

Delphi:

SQL.Text := 'SELECT SUM(tijdsduur) AS totaal ' +
            'FROM ' + Trim( DBLookupComboBox_Tabel.Text ) + ' ' +
{            'WHERE (datum LIKE ' + '''____-__-__''' + ')';}
            'WHERE (datum LIKE ' + '''12/__/2004''' + ')';

Dit blijkt ook niet te werken . Ik krijg geen resultaten terug.

Onderstaande vang ik op met de Profiler die bij MSSQL zit:

SQL:

SELECT SUM(tijdsduur) AS totaal FROM test WHERE (datum LIKE '12/__/2004')

Ziet er goed uit. Even in de Query Analizer plakken. Hier krijg ik een NULL terug. Blijkbaar doe ik nu iets fout want er zijn wel gewoon datums die als maand 12 hebben en als jaar 2004.

[ Voor 11% gewijzigd door zwik op 15-04-2004 10:24 ]

[whoami]

Als datum een datetime field is, kan je er ook geen LIKE op loslaten.
Kijk eens even inde books online naar de datetime functies en conversie-functies.

Het is al een tijdje geleden dat ik nog wat op Sql Server gedaan heb, maar er is wel zoiets als een YEAR(), MONTH(), etc.... method.

[zwik]

Delphi32 schreef op 15 april 2004 @ 10:11:
Mja ik ken dit gedrag ook alleen van situaties waarin de sum leeg is (NULL) omdat de set waarover gesommeerd wordt, leeg is (geen records -> geen optelling -> = NULL), of een null value in het gesommeerde veld bevat. Je hebt zelf al uitgesloten dat er NULL values in je veld Tijdsduur zaten (toch?).
Dus ofwel je set wordt door de WHERE leeggegooid ofwel je had een resultaat mogen verwachten. Volgens jou levert de query met WHERE in Query Analyzer een waarde op, dus die sluiten we ook uit.

Blijft over: je had een resultaat mogen verwachten maar je krijgt het niet. Nou, ga maar versienummers controleren dan Welke versie MSSQL? Welke versie ADO (niet geheel onbelangrijk)? Welke versie Delphi? Eventuele patches geïnstalleerd?

Ik gebruik MSSQL versie 8.00 (Deze zit bij Windows Server 2003 Small Business Server 2003) Deze is verder helemaal up2date. Op het development station draait een volledige gepatchte Windows XP Pro i.c.m. met een ongepatchte Delphi 7 met ADO 2.7.

[cameodski]

zwik schreef op 15 april 2004 @ 10:23:

SQL:

SELECT SUM(tijdsduur) AS totaal FROM test WHERE (datum LIKE '12/__/2004')

Ziet er goed uit. Even in de Query Analizer plakken. Hier krijg ik een NULL terug. Blijkbaar doe ik nu iets fout want er zijn wel gewoon datums die als maand 12 hebben en als jaar 2004.

Je kunt hier beter het volgende van maken:

SQL:

SELECT SUM(tijdsduur) AS totaal FROM test WHERE (datum BETWEEN '20041201 AND '20041231 23:59:59.997')

Eventueel kun je het ook zo doen, maar dan kan MSSQL geen indexen gebruiken.

SQL:

SELECT SUM(tijdsduur) AS totaal FROM test WHERE (DATEPART (year, datum) = 2004 AND DATEPART (month, datum) = 12)

[whoami]

Waarom verkies jij om gebruik te maken van DATEPART ipv 'YEAR()', MONTH() en DAY()?
Of is het gewoon een kwestie van voorkeur ?

[zwik]

Ok. Ik heb even het stukje van cameodski gecopy/paste omdat ik er zelf nog niet helemaal uit was. Heb het even in de Query Analizer gestopt en er kwam gewoon een resultaat namelijk het getal 11.

Fijn! Ik heb de query in m'n programma gestopt en waarempel, geen results . Met de Profiler gekeken en het was op het karakter precies dezelfde query als die van cameodski. Even met een MD5 sum gekeken nog maar het is echt precies dezelfde (ondertussen begin ik aan mezelf te twijfelen na al dat gepruts ).

Het begint er inderdaad sterk op te lijken dat er ergens een versie conflict ofzo is. Of zou het aan de DBGrid of ADOTable liggen?

[whoami]

Voer eens die query gewoon uit in je Delphi programma:

code:

Query1.SQL.Text := 'SELECT COUNT ..... ";
Query1.Open();
MessageDlg (IntToStr (Query1.Fields[0].AsInteger), mtInformation, [mbOk], 0);

_{Bovenstaande code gebruikt wel geen ADO componenten, maar je kan dit wel zel ff vertalen natuurlijk.}

[cameodski]

whoami schreef op 15 april 2004 @ 10:47:
Waarom verkies jij om gebruik te maken van DATEPART ipv 'YEAR()', MONTH() en DAY()?
Of is het gewoon een kwestie van voorkeur ?

Is inderdaad een kwestie van voorkeur.
Belangrijkste reden is, dat er geen aparte functies zijn voor quarter, week, weekday, hour, minute, second en millisecond, zodat ik in dat geval dus wel de DATEPART functie moet gebruiken.
Verder het heeft te maken met de functies DATEADD, DATEDIFF en DATENAME die er best wel veel op lijken en waardoor de manier van aanroepen makkelijker is te onthouden.

[zwik]

whoami schreef op 15 april 2004 @ 11:15:
Voer eens die query gewoon uit in je Delphi programma:

code:

Query1.SQL.Text := 'SELECT COUNT ..... ";
Query1.Open();
MessageDlg (IntToStr (Query1.Fields[0].AsInteger), mtInformation, [mbOk], 0);

_{Bovenstaande code gebruikt wel geen ADO componenten, maar je kan dit wel zel ff vertalen natuurlijk.}

Ik snap denk ik niet echt wat je bedoelt. Je wilt dus het aantal records in de tabel tellen neem ik aan?

Klein foutje in je code. Je kan ook gewoon AsString gebruiken zodat je geen conversie functie nodig hebt.

[whoami]

zwik schreef op 15 april 2004 @ 11:29:
[...]

Ik snap denk ik niet echt wat je bedoelt. Je wilt dus het aantal records in de tabel tellen neem ik aan?

Gewoon testen of die query werkt vanuit Delphi, of als het ergens te maken heeft met je Grid / Dataset koppeling oid.

Klein foutje in je code. Je kan ook gewoon AsString gebruiken zodat je geen conversie functie nodig hebt.

't Is maar wat je netter vindt.

[zwik]

De uitvoer is zoals we gewend zijn NULL. Er komt gewoon helemaal niets in de MessageDlg. Terwijl deze in de query Analizer gewoon het aantal records teruggeeft.

[cameodski]

Heb je het al geprobeerd zonder de ADO componenten? Dus gewoon alleen een TQuery gebruiken.

[zwik]

Hoe wil ik dat doen? Een normale TQuery ondersteund zover ik weet geen connecties over een netwerk met een MSSQL server. Verder wil ik het als het kan in ADO blijven doen omdat dbExpress depricated zijn.

[ Voor 26% gewijzigd door zwik op 15-04-2004 11:55 ]

[cameodski]

Een TQuery kun je daar ook voor gebruiken. Alleen zul je dan even een ODBC aan moeten maken.

[zwik]

Met het normale Query component wil het ook niet lukken. ODBC connectie lukt wel maar ik krijg wederom geen results.

[Just_a_Gamer]

zwik schreef op 15 april 2004 @ 11:53:
Hoe wil ik dat doen? Een normale TQuery ondersteund zover ik weet geen connecties over een netwerk met een MSSQL server. Verder wil ik het als het kan in ADO blijven doen omdat dbExpress depricated zijn.

Depricated? Dat is iets nieuws voor mij. BDE (TQuery componenten etc.) zijn depricated. Die worden niet meer verder ontwikkeld of ondersteunt.

dbExpress is juist het technologie die door borland wordt aangeraden om te gebruiken ipv BDE.

Back on topic:

Je zegt:

zwik schreef op 15 april 2004 @ 09:29:
[...]


- Wanneer ik de like weghaal krijg ik geen resultaten en lijkt geen enkel effect te hebben op de uitvoer.

Eigenlijk bedoel ik de hele where statement weghalen. (ik neem aan dat je dat hebt gedaan) Als die zo'n simpele SQL al niet doet

[zwik]

Just_a_Gamer schreef op 15 april 2004 @ 13:48:
Depricated? Dat is iets nieuws voor mij. BDE (TQuery componenten etc.) zijn depricated. Die worden niet meer verder ontwikkeld of ondersteunt.

dbExpress is juist het technologie die door borland wordt aangeraden om te gebruiken ipv BDE.

Ik bedoel dat MSSQL dat niet meer gaat ondersteunen later (staat ergens op de stie van MSSQL, kan zo vlug geen linkje vinden). En omdat ze ADO wel blijven ondersteunen heb ik ervoor gekozen om dat te gebruiken. En omdat ze hier nogal update-geil zijn willen we natuurlijk wel kunnen blijven werken.

Eigenlijk bedoel ik de hele where statement weghalen. (ik neem aan dat je dat hebt gedaan) Als die zo'n simpele SQL al niet doet

Heb ik ook al geprobeerd, en zojuist weer een keer. Er blijven alleen results komen in de Query Analizer.

[ Voor 6% gewijzigd door zwik op 15-04-2004 14:09 ]

[Delphi32]

Tjsa... wordt wel wat lastig nu. Als ik het goed samenvat:
- het kan bijna geen ADO probleem zijn, aangezien ook ODBC hetzelfde gedrag vertoont;
- het kan ook geen TADOQuery probleem zijn, aangezien een alternatief component exact hetzelfde gedrag vertoont;
- het wordt (neem ik aan... try Access direct query eens just to be sure) niet veroorzaakt door SQL Server
- het wordt ook niet veroorzaakt door je query zelf, aangezien SQL Server de juiste data rapporteert -> query is (los van de datetime/varchar discussie) goed
- het beschreven gedrag (query met sum levert een null value op) komt voor als de data een null value bevat of geen records om over te sommeren

Dan resten nog maar 2 vragen voor zover ik kan zien:
1. zit je überhaupt wel in de goeie database te kijken? Dat je zeg maar per ongeluk een gevulde database gebruikt in Query Analyzer, maar vanuit je Delphi app naar een lege database (of db met null values in de te sommeren records) zit te staren?
2. levert SQL Server, gesteld dat je 1. (na controle uiteraard) met Ja hebt beantwoord, aan andere tools wel de goeie waarden? Ik suggereerde al Access, ik heb hier ook nog wel een light Query Analyzer (Delphi 5) waarmee je het mag proberen (msn of mail me daarover).

[zwik]

Ik zie het niet echt meer zitten . Daarom stel ik het volgende voor:

Zou iemand zo vriendelijk willen zijn om een test applicatie te maken met ADO componenten en met een een vergelijkbare query m.b.v. bijvoorbeeld een Access database.

Dan kan ik stap voor stap nakijken bij elk component wat ik fout doe. Volgens mij moet daar de fout ergens zitten.

[Delphi32]

zwik schreef op 16 april 2004 @ 11:21:
Ik zie het niet echt meer zitten . Daarom stel ik het volgende voor:

Zou iemand zo vriendelijk willen zijn om een test applicatie te maken met ADO componenten en met een een vergelijkbare query m.b.v. bijvoorbeeld een Access database.

Dan kan ik stap voor stap nakijken bij elk component wat ik fout doe. Volgens mij moet daar de fout ergens zitten.

Ik wil wel helpen. Stuur ff backupje van je database + je query op naar me, dan ga ik ernaar kijken. Mail mag naar [e-mail].

[zwik]

Hier ben ik weer .

Ik wil even aangeven dat het me vandaag gelukt is om er results uit te krijgen. Het is met niet gelukt om met behulp van een SUM query naar de server toe resultaten te krijgen. Ik heb het opgelost door het op de server te doen. Dat wil zeggen dat ik een view gemaakt heb met met eenzelfde SUM query. Het leuke hiervan is, is dat er eigenlijk precies hetzelfde gebeurd. Maar in plaats van een waarde krijg je nu een kleine tabel met die waarde.
Dus eigenlijk het hetzelfde, maar het gewenste resultaat is wel hetzelfde .

Toch wil ik iedereen nog even bedanken voor de hulp en kleine verbeteringen van het programma want het werkt . Bedankt.

[LordLarry]

Begrijp ik je nou goed? Je voert een query uit en wil het resultaat in een TADOTabel hebben? Zo werkt het niet hoor. een TADOTable is alleen een versimpelde TADOQuery die standaard 'select * from TableName' uitvoert als query. Er bestaat geen relatie tussen een resultaat van een query in een ander component en jouw TADOTable. Je TADOQuery bevat gewoon het resultaat van de Query die je uitvoert. SUM, COUNT en de rest hoort gewoon te werken in je query. Het resultaat van de TADOQuery kan je direct uit het component lezen dmv FieldByName enz en als je op het scherm wilt tonen gebruik je een TDataSource en een TDBGrid om ze te koppelen.

Met Table.Insert voeg je een nieuwe record toe aan de tabel en lijkt me niet wat jij bedoelt.

Volgensmij is jouw probleem ook niet echt een bug, maar eerder dat je niet helemaal begrijpt hoe de TDataSets binnen Delphi werken.

[zwik]

LordLarry schreef op 29 april 2004 @ 11:06:
Begrijp ik je nou goed? Je voert een query uit en wil het resultaat in een TADOTabel hebben? Zo werkt het niet hoor. een TADOTable is alleen een versimpelde TADOQuery die standaard 'select * from TableName' uitvoert als query. Er bestaat geen relatie tussen een resultaat van een query in een ander component en jouw TADOTable. Je TADOQuery bevat gewoon het resultaat van de Query die je uitvoert. SUM, COUNT en de rest hoort gewoon te werken in je query. Het resultaat van de TADOQuery kan je direct uit het component lezen dmv FieldByName enz en als je op het scherm wilt tonen gebruik je een TDataSource en een TDBGrid om ze te koppelen.

Met Table.Insert voeg je een nieuwe record toe aan de tabel en lijkt me niet wat jij bedoelt.

Volgensmij is jouw probleem ook niet echt een bug, maar eerder dat je niet helemaal begrijpt hoe de TDataSets binnen Delphi werken.

Misschien begrijp ik het inderdaad niet . Het rare is dat ik ook gewoon voorbeelden op internet gevolgd heb met precies hetzelfde resultaat, niks dus . ParamByName heb ik ook gebruikt maar krijgt er ook niet echt iets uit.

Gelukkig werkt het nou, dus kan ik weer verder prutsen .