---

Hej NG

Jeg har et problem som jeg er gået "død" på.

I en tabel har jeg nogle oplysninger om en bils start og stop tider:



Bil1 Start 10.00 Sted1

Bil1 Stop 10.20 Sted2

Bil1 Start 10.20 Sted2

Bil1 Stop 11.05 Sted3



OSV.



Jeg skal have oprette en rapport der viser "køretid"



Bil1 Sted2 0.20

Bil1 Sted3 0.45



Jeg kan ikke finde en løsning på dette, så al hjælp modtages meget gerne.



Tue

---

Tue Hellstern wrote:
> Jeg skal have oprette en rapport der viser "køretid"

Med hvilket værktøj?

--
Lars Kongshøj

---

"Tue Hellstern" <info@f1-support.dk> wrote
> I en tabel har jeg nogle oplysninger om en bils start og stop tider:

Hvilken felttype er feltet med tiderne, og hvilken database snakker vi?

--
Jakob Andersen

---

Hej Jakob
> Hvilken felttype er feltet med tiderne, og hvilken database snakker vi?

De er pt Tekst, men de kan oprettes i hvad det skal være, hvis det løser
problemet.
PT. er det en Access databse, men det skal enten over på en MySql eller en
MSSql server.

Tue

---

"Tue Hellstern" <info@f1-support.dk> wrote
> De er pt Tekst, men de kan oprettes i hvad det skal være, hvis det løser
> problemet.
> PT. er det en Access databse, men det skal enten over på en MySql eller en
> MSSql server.

Hvis du bruger Access eller MS SQL kan du have en fordel i at lægge dem om
til datetime felter, og så kan du vha. DateDiff funktionen udregne
tidsforskel imellem to tider.

--
Jakob Andersen

---

Hej Jakob
> Hvis du bruger Access eller MS SQL kan du have en fordel i at lægge dem om
> til datetime felter, og så kan du vha. DateDiff funktionen udregne
> tidsforskel imellem to tider.

Det er ikke så meget selev beregningen, men hvordan får jeg mulighed for at
udføre beregningen. Det er jo et tal fra en anden linje, den oven over, der
skal trækkes (eller DataDif) fra den næste linje. Start tid kommer i en
række og stop tid kommer i en anden række.

Tue

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Tue Hellstern" <info@f1-support.dk> writes:

> Jeg har et problem som jeg er gået "død" på.

Ja, sådan går det ofte, når man er uerfaren. Man begår en masse fejl,
lærer af dem, og pludseligt er man ikke så uerfaren længere. Så bliver
det først rigtigt sjovt, for så er det alle de interessante problemer,
man går død på.

> I en tabel har jeg nogle oplysninger om en bils start og stop tider:
> Bil1 Start 10.00 Sted1
[...]
> OSV.

Ville det ikke give bedre mening med en tabel, der ser ud noget i
retning af dette:

bil | starttid | stoptid | startsted | stopsted
----+----------+---------+-----------+---------
b1 | t0 | t1 | s0 | s1
b1 | t | NULL | s1 | NULL

osv.

I række 2 mangler der tydeligtvis ankomstinformation. Hvis alt går
vel, antaget at databasen opdateres i 'rigtig rækkefølge', kan der til
enhver tid kun være én sådan række for hver bil, og der vil altid være
en sådan række, når databasen opdateres med bilens ankomst. Så
opdaterer du 'alle' rækker med bilens ID, hvor stoptid og stopsted er
NULL.

På denne måde har du designet dig udenom problemet. Forespørgsler på
køretid bliver dermed meget enkle. Hvis tiderne er standard SQL92
timestamps, skulle man kunne lave forespørgsler som

SELECT SUM(stoptid - starttid) FROM tabel
WHERE bil = b1
AND starttid >= '2002-10-14 00:00:00'
AND stoptid < '2002-10-15 00:00:00';

der fortæller dig, hvor meget bil b1 har kørt i dag.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj2q+kAACgkQYu1fMmOQldVXNACeOZFsnhbWcKh3XHsGv7DawPA8
sVkAoLoRVH5FOOq/g1lCWyUqT5bJAvxE
=Ugb6
-----END PGP SIGNATURE-----

---

Tue Hellstern wrote:
>
> Hej NG
>
> Jeg har et problem som jeg er gået "død" på.
>
> I en tabel har jeg nogle oplysninger om en bils start og stop tider:
>
> Bil1 Start 10.00 Sted1
> Bil1 Stop 10.20 Sted2
> Bil1 Start 10.20 Sted2
> Bil1 Stop 11.05 Sted3
>
> OSV.
>
> Jeg skal have oprette en rapport der viser "køretid"
>
> Bil1 Sted2 0.20
> Bil1 Sted3 0.45
>
> Jeg kan ikke finde en løsning på dette, så al hjælp modtages meget gerne.

Der er sikkert allerede andre, der har svaret. Men jeg har downloadet
for flere timer siden, og ligge nu *har* jeg tiden til at svare, så:

Select t1.bil, t2.tid - t1.tid
from tabel t1
join tabel t2
on t1.bil = t2.bil
on t1.sted = t2.sted
where t1.start_stop = 'stop'
and t2.start_stop = 'start'
and t2.tid =
(select min(t3.tid)
from tabel t3
where t3.bil = t2.bil
and t3.sted = t2.sted
and t3.start_stop = 'start'
and t3.tid > t1.tid)

(Hm. En tabel joinet med sig selv tre gange, og ingen af gangene med et
meget restriktivt join. Jeg garanterer *ikke* for køretiden af det her.)

Jeg går ud fra, at en bil godt kan vende tilbage til det sammensted. I
modsat fald kan hele subselecten udelades.

Og hvis nogen trænger til udfordring, kan de jo prøve at lave den
akkumulerede sum for en serie posteringer.

POSTERING(post_id, dato, debet, kredit)

Eksempeldata

1   2002-10-10   NULL   5
2   2002-10-11   10   NULL
3   2002-10-12   25   NULL
4   2002-10-13   NULL   30

Ønsket output

Dato      Bevægelse   Saldo
2002-10-10   5      5
2002-10-11   -10      -5
2002-10-12   -25      -30
2002-10-13   30      0

Eller på dansk: Lav et kontoudtog!

--
Kristian Damm Jensen | Feed the hungry at www.thehungersite.com
kristian-damm.jensen@cgey.com | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Damm Jensen <kristian-damm.jensenRE@MOVEcgey.com> writes:

> (Hm. En tabel joinet med sig selv tre gange, og ingen af gangene med et
> meget restriktivt join. Jeg garanterer *ikke* for køretiden af det her.)

Når det er nødvendigt for at lave en simpel forespørgsel, er det altid
et sikkert tegn på, at der er noget galt med ens skema.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAj2r3qsACgkQYu1fMmOQldVAeACgsSaJne1H1ruGMlYY7vOAiNz8
7rcAnArtJ9RiSlQB2u33F3ZXq0r04bAJ
=y4ZF
-----END PGP SIGNATURE-----

---

Hej Martin
> Når det er nødvendigt for at lave en simpel forespørgsel, er det altid
> et sikkert tegn på, at der er noget galt med ens skema.

Hvis du har et forslag til hvordan tabellen kan opbygges på en anden måde er
jeg meget åbne for forslag.
Tue

---

Tue Hellstern wrote:
>
> Hej Martin
> > Når det er nødvendigt for at lave en simpel forespørgsel, er det altid
> > et sikkert tegn på, at der er noget galt med ens skema.
>
> Hvis du har et forslag til hvordan tabellen kan opbygges på en anden måde er
> jeg meget åbne for forslag.
> Tue

Martin sendte allerede i går aftes et forslag til en anden struktur, som
vil løse dit problem.

- Forudsat, selvfølgelig, at du (a) enten får data på papir, og skal
taste dem ind under alle omstændigheder (b) eller får dem i et
elektronisk format, der gør det relativt nemt at lægge dem ind, som
Martin foreslår.


--
Kristian Damm Jensen | Feed the hungry at www.thehungersite.com
kristian-damm.jensen@cgey.com | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.