Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   MSSQL Stored Procedure -> datetime vergleichsprobleme??? (https://www.delphipraxis.net/113414-mssql-stored-procedure-datetime-vergleichsprobleme.html)

cherry 7. Mai 2008 15:37


MSSQL Stored Procedure -> datetime vergleichsprobleme???
 
hi

ich schreibe ein delphiprogramm das folgende storedprocedure verwendet:

SQL-Code:
ALTER PROCEDURE [dbo].[p_bb_ignore_folder]
@username varchar(30),
@ignore_dir varchar(255),
@date_time datetime

AS
DECLARE
  @size bigint,
  @id_user int

SET @size = -1;
SET @id_user = (SELECT [t_bb_user].[id_user] FROM [t_bb_user] WHERE [t_bb_user].[username] = @username);
SET @size = ( SELECT SUM([t_bb_folder_info].[folder_size]) FROM [t_bb_folder_info]
  WHERE ( 
          ([t_bb_folder_info].[folder] LIKE @ignore_dir+'%')
          AND ([t_bb_folder_info].[id_user] = @id_user)
          AND ([t_bb_folder_info].[date_time] = @date_time)
  )
);

UPDATE t_bb_logon
SET
  [t_bb_logon].[ignore_dir_size] = @size
WHERE (
        ([t_bb_logon].[id_user] = @id_user)
        /*AND ([t_bb_logon].[date_time] = @date_time)*/ 
         
);
das Problem liegt in dieser Zeile (in der ersten WHERE Klausel):
SQL-Code:
AND ([t_bb_folder_info].[date_time] = @date_time)
also obwohl in der tabelle mehrere Einträge vorhanden sind die dieser Bedinung entspechen, meint sql das es eben nicht so ist...

lasse ich die Zeile weg oder kommentiere ich sie aus, passiert was passieren soll..

kann ich das:
SQL-Code:
AND ([t_bb_folder_info].[date_time] = @date_time)
grundsätzlich nicht so machen?
ich will die bedingung , dass nur die "folder_size" zusammengezählt werden, die im feld "date_time" = "@date_time" haben...

is schwierig zu erklären, kommt ihr da mit, oder hab ich nur stuss erzählt? wäre um jede Hilfe froh, bin schon seit drei Tagen an dieser Procedure und kreigs einfach nicht hin...

Danke schon mal...

Jelly 7. Mai 2008 15:47

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Du hast eventuell nicht berücksichtig, dass ein Datetime auf Stunden, Minuten, Sekunden und Millisekundenanteile hat... Ich denke, da solltest du dein Problem eventuell finden.

cherry 7. Mai 2008 15:54

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
? ne, is alles genau gleich, scheint jedenfalls so..

SQL-Code:
2008-05-07 16:12:52.000 = 2008-05-07 16:12:52.000
oder nicht?

shmia 7. Mai 2008 15:58

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Der Datetime Datentyp des SQL Server hat eine Genauigkeit von einer 3/100 Sekunden.
Der Delphi Datentyp hat eine höhere Genauigkeit; auf jeden Fall können Rundungsfehler bei der Umrechnung auftreten.
Also darf man eigentlich den Datentyp Datetime nicht auf Gleichheit überprüfen !!

Du könntest nun einen Trick anwenden und deine Zeitwerte vorher runden:
Delphi-Quellcode:
function RoundedDateTime(value:TDateTime):TDateTime;
begin
  result := Round(value * 32768) / 32768;
end;
Also anstatt den Wert von Now() direkt zu verwenden, einmal durch obige Funktion jagen und in eine TDateTime Variablen speichern. Dann nur mit diesem Wert arbeiten, denn Now() läuft ja weiter...

cherry 7. Mai 2008 16:04

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
hmm klingt eigentlich logisch aber:

1. im code nehme ich die zeit Now; nur einmal, speichere es in eine variable und arbeite dann mit dieser weiter.
schreibe meine Einträge in die Datenbank und wende die Proc "p_bb_ignore_folder" an währen dieses ganzen Ablaufs
verwende ich immer die selbe Variable.

2. für den Test der Funktion habe ich die Procedure direkt vom MSSQL Server Management Studio ausgeführt und
kopiere den exakten Wert aus der Tabelle womit die Ungenauigkeit eigentlich auch verhindert werden sollte...

aber wahrscheinlich haste trotzdem irgendwie recht, denn ersetze ich

SQL-Code:
AND ([t_bb_folder_info].[date_time] = @date_time)
mit

SQL-Code:
AND ([t_bb_folder_info].[date_time] <> @date_time)
passiert ja was... also scheinen die dati trotzdem nicht überein zu stimmen. aber wo ist der Fehler?

p80286 7. Mai 2008 16:26

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hallo Cherry,

leider kann ich Dir nichts genaues sagen, aber ich verute das Du zwar nicht Äpfel mit Birnen aber Boskop mit Granny Smith vergleichst.

Soweit ich weiß gibt es mindestens zwei unterschiedliche "Zeit-Typen" Datum und Timestamp und die beiden sind nicht kompatibel.
Wenn Du also vergleichst, dann nur über ein "Zwischenformat" wie z.B.

SQL-Code:
to_char(trunc(sysdate),'YYYYMMDD')=to_char(trunc(startdat),'YYYYMMDD')
Hier bist Du Herr des Geschehens weil Du beide Seiten des Vergleichs definiert hast.

Gruß
K-H

NormanNG 7. Mai 2008 16:35

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

Zitat:

to_char(trunc(sysdate),'YYYYMMDD')=to_char(trunc(s tartdat),'YYYYMMDD')
wenn ich mich nicht irre, wird das in MSSQL nicht gehen. :gruebel:

Ich würde mit datediff(...) arbeiten:

SQL-Code:
where datediff( ss, date_time, @date_time ) < 1

p80286 7. Mai 2008 16:49

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Pardon da hab ich mich vergallopiert,
aber das Prinzip ist das gleiche.

( ist schon toll wie kompatibel die SQL-Dialekte sind)

Gruß
K-H

NormanNG 7. Mai 2008 16:55

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

Zitat:

Zitat von p80286
...
aber das Prinzip ist das gleiche.

Nicht ganz. :-D
Hier wird eine Sekundendifferenz gebildet.
Wenn der TE mehrere Datensätze für einen Tag hat,
aber nur die mit an diesem Tag mit der gewünschten Zeit ansprechen möchte,
dann greift dein Vergleich auf falsche Daten zu.

alzaimar 7. Mai 2008 17:09

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Die Funktion 'DateDiff' wird den Einsatz eines Index verhindern. Ich verwende bei DateTime-Vergleichen immer 'BETWEEN', hier wäre das z.B.
SQL-Code:
WHERE Table.DateTimeField Between DateAdd(minute,-1,@Date) and DateAdd (minute,1,@Date)
  AND dbo.DateOnly (Table.DateTimeField) = dbo.DateOnly(@Date)
Wobei 'dbo.DateOnly' eine UDF ist, die den Datumsanteil eine DateTime-Wertes liefert.
SQL-Code:
CREATE FUNCTION [dbo].[DateOnly] (@Date DateTime)
RETURNS Datetime AS
BEGIN
  Return cast (floor (cast (@Date as float)) as DateTime)
END
Die Werte der BETWEEN-Klausel werden vom Optimizer in Konstanten (ggü der Tabelle) übersetzt und damit kann der Index greifen. Bei Datediff geht das nicht, weil ja jedesmal die Differenz gebildet werden muss.

NormanNG 7. Mai 2008 17:16

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

Zitat von alzaimar
Die Funktion 'DateDiff' wird den Einsatz eines Index verhindern....

Das mit dem Index stimmt natürlich.

Aber der Minutenbereich ist doch eigendlich zu groß?
SQL-Code:
WHERE Table.DateTimeField Between DateAdd(minute,-1,@Date) and DateAdd (minute,1,@Date)
Damit wird doch nicht nur die gewünschte Zeit, sondern auch 1 Minute vorher/nachher zurückgeliefert, oder?

alzaimar 7. Mai 2008 20:51

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Dann nimm halt ne Sekunde ('second') oder 'millisecond'.

cherry 8. Mai 2008 06:02

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

Zitat von alzaimar
Die Funktion 'DateDiff' wird den Einsatz eines Index verhindern. Ich verwende bei DateTime-Vergleichen immer 'BETWEEN', hier wäre das z.B.
SQL-Code:
WHERE Table.DateTimeField Between DateAdd(minute,-1,@Date) and DateAdd (minute,1,@Date)
  AND dbo.DateOnly (Table.DateTimeField) = dbo.DateOnly(@Date)
Wobei 'dbo.DateOnly' eine UDF ist, die den Datumsanteil eine DateTime-Wertes liefert.
SQL-Code:
CREATE FUNCTION [dbo].[DateOnly] (@Date DateTime)
RETURNS Datetime AS
BEGIN
  Return cast (floor (cast (@Date as float)) as DateTime)
END
Die Werte der BETWEEN-Klausel werden vom Optimizer in Konstanten (ggü der Tabelle) übersetzt und damit kann der Index greifen. Bei Datediff geht das nicht, weil ja jedesmal die Differenz gebildet werden muss.

also wenn ich jetzt mal von dem aus gehe... habe ich noch ein paar fragen...

1.) reicht das nicht schon alleine?
SQL-Code:
WHERE Table.DateTimeField Between DateAdd(second,-1,@Date) and DateAdd (second,1,@Date)
2.) wozu ist denn das hier jetzt genau?!:
SQL-Code:
AND dbo.DateOnly (Table.DateTimeField) = dbo.DateOnly(@Date)
3.) und was die Funktion DateOnly genau aus meinem Datum macht erkenn ich auch nicht so auf den ersten Blick?!

aber vielen Dank schon mal für die vielversprechenden Antworten

//EDIT

sehe ich das richtig:
dieses hier:
SQL-Code:
WHERE Table.DateTimeField Between DateAdd(second,-1,@Date) and DateAdd (second,1,@Date)
vergleicht nur die sekunden, nicht aber das Datum und die Zeit auf sekunden genauigkeit?

deshalb muss ich mit
SQL-Code:
AND dbo.DateOnly (Table.DateTimeField) = dbo.DateOnly(@Date)
noch das Datum vergleichen?

trotzdem was macht die Funktion DateOnly genau?

NormanNG 8. Mai 2008 06:35

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

Zitat:

Zitat von cherry
trotzdem was macht die Funktion DateOnly genau?

intern werden datetime-Werte als float gespeichert, wobei das Datum im
Vorkomma- und die Zeit im Nachkommateil abgebildet sind. Die DateOnly-Funktion
macht nichts anderes, als den Nachkommateil abzuschneiden.

cherry 8. Mai 2008 06:41

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
achso, dann kapier ich jetz DateOnly ;-)

aber: hab mal kurz einen neuen Versuch gestartet und in der WHERE Klausel steht jetzt nur noch folgendes:

weder so...

SQL-Code:
[t_bb_folder_info].[date_time] Between DateAdd(hour,-1,@date_time) and DateAdd(hour,1,@date_time)
noch so...

SQL-Code:
DateAdd(hour,0,[t_bb_folder_info].[date_time]) Between DateAdd(hour,-1,@date_time) and DateAdd(hour,1,@date_time)
... findet sql die gewünschten datensätze mein SELECT SUM() gibt also NULL resp. 0 zurück ;-(

ich mach wohl noch was anderes falsch, aber was denn?

NormanNG 8. Mai 2008 06:58

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

um zu sehen, mit welchen Werten gearbeitet wird, lass dir die Daten doch mal anzeigen:

SQL-Code:
select DateAdd(hour,-1,@date_time), DateAdd(hour,1,@date_time), [t_bb_folder_info].[date_time] ...
Das hier übrigends...
SQL-Code:
where DateAdd(hour,0,[t_bb_folder_info].[date_time]) Between ...
hat wieder das Problem mit dem Index, da die Tabellenspalte in einer Funktion "verpackt" ist
und somit kein Index verwendet werden kann.

cherry 8. Mai 2008 06:58

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
wie wärs dann damit?

SQL-Code:
CAST([t_bb_folder_info].[date_time] AS CHAR(25)) = CAST(@date_time AS CHAR(25))
geht bei mir aber leider auch net...
ich hab so langsam aber sicher das Gefühl, dass bei mir etwas ganz faul ist...

denn wenn ich ein select auf mein gespeichertes datum mache sieht das so aus:
SQL-Code:
2008-05-07 15:16:32.000
wenn ich nun meine procedure ausführe und als @date_time parameter ebenfalls
SQL-Code:
2008-05-07 15:16:32.000
mitgebe funktioniert ja das alles nicht mit keiner bisher getesteten variante...

Zitat:

Zitat von NormanNG
intern werden datetime-Werte als float gespeichert, wobei das Datum im
Vorkomma- und die Zeit im Nachkommateil abgebildet sind. Die DateOnly-Funktion
macht nichts anderes, als den Nachkommateil abzuschneiden.

kann ich jetzt davon ausgehen das z.B. eben ein mit select ausgelesenes feld z.B. "2008-05-07 15:16:32.000" ergibt, nicht dasselbe ist wie:
SQL-Code:
CAST("2008-05-07 15:16:32.000" AS datetime);
???

//EDIT

Zitat:

Zitat von cherry
wie wärs dann damit?
SQL-Code:
CAST([t_bb_folder_info].[date_time] AS CHAR(25)) = CAST(@date_time AS CHAR(25))

erübrigt sich wohl wegen des indexes, richtig?! :P hab doch schon was gelernt

cherry 8. Mai 2008 07:04

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

Zitat von NormanNG
Hi,

um zu sehen, mit welchen Werten gearbeitet wird, lass dir die Daten doch mal anzeigen:
SQL-Code:
select DateAdd(hour,-1,@date_time), DateAdd(hour,1,@date_time), [t_bb_folder_info].[date_time] ...

funktioniert, aber was bringt mir das nun... (sorry 1. morgen in der früh... 2. ich bin kein blitzmerker)

ausgabe:

SQL-Code:
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
usw

NormanNG 8. Mai 2008 07:09

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

lass doch erstmal alles Andere weg und bau dir eine Select-Anweisung
zusammen, die das Gewünschte liefert. Dazu nimmst du das SQl-Query-Tool oder
die Management-Console von MS. Wenn das Select dann funktioniert, gehts
in Delphi weiter...

Wenn´s dann immer noch nich klappt, poste mal eine paar Beispieldaten samt deinem
kompetten Select. :wink:


Zitat:

funktioniert, aber was bringt mir das nun... (sorry 1. morgen in der früh... 2. ich bin kein blitzmerker)
Das das funktioniert ist klar. Du sollst dir die Spalten ansehen und prüfen, ob deine
Bedingung richtig fornuliert ist.

cherry 8. Mai 2008 07:15

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
SQL-Code:
declare
  @date_time datetime
SET @date_time = CAST('2008-05-07 15:16:32.000' AS datetime);
SELECT folder_size FROM [t_bb_folder_info]
where [t_bb_folder_info].[date_time] Between DateAdd(hour,-1,@date_time) and DateAdd(hour,1,@date_time)
gibt mir keinen einzigen datensatz zurück...
obwohl

SQL-Code:
declare
  @date_time datetime
SET @date_time = CAST('2008-05-07 15:16:32.000' AS datetime);
SELECT DateAdd(hour,-1,@date_time), DateAdd(hour,1,@date_time), [t_bb_folder_info].[date_time] FROM [t_bb_folder_info]
folgendes zurück gibt:

SQL-Code:
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
.
.
.

NormanNG 8. Mai 2008 07:20

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
2008-07-05 14:16:32.000 ¦ 2008-07-05 16:16:32.000 ¦ 2008-05-07 15:16:32.000
In deinem @date_time sind Monat und Tag vertauscht!


SQL-Code:
declare @Date_Time datetime
set @Date_Time = '2008-05-07 15:16:32'

select *
from [t_bb_folder_info]
where [t_bb_folder_info].[date_time] between DateAdd(second, -1, @Date_Time) and DateAdd(second, 1, @DateTime)
getippt und nicht getestet

cherry 8. Mai 2008 07:28

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Also jetzt seh ichs auch aber Hallo, da stimmt doch definitiv etwas nicht?! *hirnschleiff*

SQL-Code:
declare
  @date_time datetime
SET @date_time = CAST('2008-07-05 15:16:32.000' AS datetime);
SELECT * FROM [t_bb_folder_info]
where [t_bb_folder_info].[date_time] Between DateAdd(second,-1,@date_time) and DateAdd(second,1,@date_time)
erzeugt folgende ausgabe

SQL-Code:
172743 ¦ C:\Dokumente und Einstellungen\th21498\            ¦ 8789271 ¦ 2008-05-07 15:16:32.000 ¦ 12
172744 ¦ C:\Dokumente und Einstellungen\th21498\borland    ¦ 5117    ¦ 2008-05-07 15:16:32.000 ¦ 12
172745 ¦ C:\Dokumente und Einstellungen\th21498\.revj0079   ¦ 4542    ¦ 2008-05-07 15:16:32.000 ¦ 12
172746 ¦ C:\Dokumente und Einstellungen\th21498\.SunDown... ¦ 97451   ¦ 2008-05-07 15:16:32.000 ¦ 12
.
.
.
also oben beim Select gebe ich dieses datetime mit: '2008-07-05 15:16:32.000' dann findet es dieses datetime '2008-05-07 15:16:32.000'

spinn ich jetzt??????????????????????? :wall:

NormanNG 8. Mai 2008 07:33

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

das liegt dann an deinem eingestellen Datumformat des SQl-Servers.
Nimm mal das

SQL-Code:
set dateformat ymd

declare @Date_Time datetime
set @Date_Time = '2008-05-07 15:16:32'

select *
from [t_bb_folder_info]
where [t_bb_folder_info].[date_time] between DateAdd(second, -1, @Date_Time) and DateAdd(second, 1, @DateTime)
[edit]
unabhängig vom eingstellten Datumformat ist folgendes

set @Date_Time = '20080507 15:16:32.000'
[/edit]

cherry 8. Mai 2008 07:39

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
hmmm...
SQL-Code:
set dateformat ymd
es ist ein produktiver MSSQL Server auf dem sehr wichtige "Programme" laufen ich schätze das kann ich mir nicht erlauben sonst werd ich noch gesteinigt :lol:

kann ich das Problem nicht anders lösen?

cherry 8. Mai 2008 07:48

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

Zitat von NormanNG
unabhängig vom eingstellten Datumformat ist folgendes
set @Date_Time = '20080507 15:16:32.000'

so würde ich ja "set dateformat ymd" umgehen, aber der parameter @Date_Time soll ja dann am Ende von Delphi an die StoredProc übergeben werden, wie lös ich denn da das Problem... muss ich zuerst das Datum konvertieren? wenn ja wie?

und heisst das mein Programm würde dann nicht mehr so richtig funktionieren wenn der SQL -Server ein anderes Datumsformat hätte?

NormanNG 8. Mai 2008 07:53

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,



Zitat:

so würde ich ja "set dateformat ymd" umgehen,
ja

Zitat:

aber der parameter @Date_Time soll ja dann am Ende von Delphi an die StoredProc übergeben werden, wie lös ich denn da das Problem... muss ich zuerst das Datum konvertieren?
Nein. Die Einstellung betrifft nur das Umwandeln von String in Datetime, also nur deinen Test im Query-Tool.
Vom Programm werden (hoffendlich) direkt Datetime-Werte geliefert.

Zitat:

und heisst das mein Programm würde dann nicht mehr so richtig funktionieren wenn der SQL -Server ein anderes Datumsformat hätte?
Wenn die Umwandlung String->Datetime benötigt und das o.g. unabhängige Format verwendet wird,
dann ist es eben unabhängig von den Server-Einstellungen.

cherry 8. Mai 2008 08:01

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
also bitte nochmals für all diejenigen, die einen IQ < 100 haben :lol:

Zitat:

Zitat von NormanNG
Nein. Die Einstellung betrifft nur das Umwandeln von String in Datetime, also nur deinen Test im Query-Tool.
Vom Programm werden (hoffendlich) direkt Datetime-Werte geliefert.

Welche Einstellung?
als Parameter wird aber bereits ein datetime Wert geliefert wie du das ja hoffst, also wo passiert dann das Umwandeln von String in Datetime... am schluss habe ich ja nirgens mehr ein String Wert.. eine solche Umwandlung wird es nie geben...

:wiejetzt:

NormanNG 8. Mai 2008 08:11

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

Nein. Die Einstellung betrifft nur das Umwandeln von String in Datetime, also nur deinen Test im Query-Tool.
Vom Programm werden (hoffendlich) direkt Datetime-Werte geliefert.
also genauer, hier

SQL-Code:
declare @Date_Time datetime
set @Date_Time = '20080507 15:16:32.000'
select ...
Wenn dein Select dann das gewünschte Ergebnis liefert, baust du das
in eine Procedure und prüft diese nochmal per Aufruf aus dem Query-Tool
(hierbei wieder das Datumformat beachten). Geht das auch, dann weiter in Delphi...

cherry 8. Mai 2008 08:13

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
ok... ich meld mich dann wieder wenn ich soweit bin...

cherry 8. Mai 2008 08:25

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
ok also SELECT funktionierte... meine StoredProc scheint es auch zu tun... so sieht sie nun aus:

SQL-Code:
ALTER PROCEDURE [dbo].[p_bb_ignore_folder]
@username varchar(30),
@ignore_dir varchar(255),
@date_time datetime

AS
DECLARE
  @size bigint,
  @id_user int

SET @size = -1;
SET @id_user = (SELECT [t_bb_user].[id_user] FROM [t_bb_user] WHERE [t_bb_user].[username] = @username);
SET @size = ( SELECT SUM([t_bb_folder_info].[folder_size]) FROM [t_bb_folder_info]
  WHERE ( 
           [t_bb_folder_info].[id_user] = @id_user
           AND [t_bb_folder_info].[folder] LIKE @ignore_dir
           AND dbo.DateOnly([t_bb_folder_info].[date_time]) = dbo.DateOnly(@Date_Time)
           AND [t_bb_folder_info].[date_time] BETWEEN DateAdd(millisecond, -1, @Date_Time) and DateAdd(millisecond, 1, @Date_Time)                      
  )
);

UPDATE t_bb_logon
SET
  [t_bb_logon].[ignore_dir_size] = @size
WHERE (
         [t_bb_logon].[id_user] = @id_user
         AND dbo.DateOnly([t_bb_logon].[date_time]) = dbo.DateOnly(@Date_Time)
         AND [t_bb_logon].[date_time] BETWEEN DateAdd(millisecond, -1, @Date_Time) and DateAdd(millisecond, 1, @Date_Time)        
);      

RETURN @size
mit dem aufruf direkt vom Server funktioniert das so:

SQL-Code:
declare
  @result bigint
 
EXEC @result = p_bb_ignore_folder 'th21498', 'C:\Dokumente und Einstellungen\th21498\Lokale Einstellungen\%', '20080507 15:16:32.000'
print CAST(@result AS CHAR(255));
alles palleti...

wie befürchtet funktioniert der Aufruf aus meiner Delphi-Applikation leider nicht. Meine Vermutung -> eben das angesprochene ydm <-> ymd Problem...

meint Aufruf in Delphi:

Delphi-Quellcode:
procedure TSisterWatch.IgnoreDir(Date_Time: TDateTime);
var
  tmp_igp: String;
begin
  tmp_igp := GetIgnoreDir;
  if tmp_igp <> '' then
  begin
    with ADOStoredProc8 do
    begin
      Parameters.ParamValues['@username'] := Username;
      Parameters.ParamValues['@ignore_dir'] := tmp_igp;
      Parameters.ParamValues['@date_time'] := Date_Time;
      ExecProc;
    end;
  end;
end;
wie stelle ich das nun an...

NormanNG 8. Mai 2008 13:54

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

hab´ heute nur wenig Zeit
wie wird denn die AdoStoredProc erstellt? Evtl. ist ein Parameter falsch definiert.
Oder es gibt ein Problem zwischen den lokalen und serverseitigen Spracheinstellungen? :gruebel:

Zwar nicht optimal, aber kurzfristig hilfreich:
definiere den Parameter @datetime in der Procedure als String
und übergebe ihn wie oben beschrieben sprachunabhängig...

cherry 9. Mai 2008 07:25

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Hi,

also die AdoStoredProc liegt genz bequem auf dem unsichtbaren "Formular?" meines Dienstes und wird nicht im Code instanziert. Ich habe die Proc nochmals neu definiert in der AdoStoredProc Komponente und die Parameter überprüft, scheint jedoch alle i.O. zu sein.
Zitat:

Zitat von NormanNG
Oder es gibt ein Problem zwischen den lokalen und serverseitigen Spracheinstellungen?

keine Ahnung! Kann ich das ausfindig machen?
Zitat:

Zitat von NormanNG
Zwar nicht optimal, aber kurzfristig hilfreich:
definiere den Parameter @datetime in der Procedure als String
und übergebe ihn wie oben beschrieben sprachunabhängig...

habs getestet. Funktioniert, aber eben, war nur ein Test. So kann ich das unmöglich stehen lassen! :zwinker:

omata 9. Mai 2008 18:52

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

Zitat von cherry
wie befürchtet funktioniert der Aufruf aus meiner Delphi-Applikation leider nicht.

Welche Fehlermeldung? oder einfach kein Ergebnis?

Hast du mal versucht von TDateTime auf TSQLTimeStamp umzustellen?

Unit: SqlTimSt

Gruss
Thorsten

cherry 11. Mai 2008 15:06

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Zitat:

Zitat von omata
Welche Fehlermeldung? oder einfach kein Ergebnis?

keine Fehlermeldung... die Procedure funktioniert auch, nur liefert sie kein oder ein falsches Ergebnis, da Monat und Tag vertauscht werden!

Ich werd dann am Dienstag mal den TSQLTimeStamp ausprobieren...
am besten werde ich gleich für sämtliche Dati di in die Datenbank geschrieben werden dieses Format verwenden oder?!

lg und bis am Dienstag... 8)

alzaimar 12. Mai 2008 18:31

Re: MSSQL Stored Procedure -> datetime vergleichsprobleme
 
Entweder verwendet man einen PArameter mit dem Datentyp 'ftDateTime', oder man formatiert die Datumsangabe so:
SQL-Code:
select * from Table where DateField = { ts '2008-05-24 12:34:56' }
oder man verwendet das Format 'yyyymmdd hh:nn:ss', das funktioniert auch (jedenfalls in T-SQL). Ich verwende das o.g. ODBC-Format. Ist nicht so gut dokumentiert, funzt aber.

Am ordendlichsten ist es aber, einen Parameter als ftDateTime zu deklarieren. ADO holt sich dann das gültige Datumsformat vom Server.


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:24 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz