[PHP/(My)SQL] voor dummies - Deel 62 | Digital Corner (DIG/DEV)

FOK!-Schrikkelbaas dinsdag 26 augustus 2008 @ 16:21:29 #101

Swetsenegger

Egocentrische Narcist

quote:
Op dinsdag 26 augustus 2008 16:13 schreef JortK het volgende:
Ik kan me best voorstellen dat je zaken niet in de browser hoeft te zien, je kan namelijk ook PHP schrijven die niets hoeft te laten zien, zoals ik zelf met een data mining project bezig ben waarbij er geen output op het scherm komt maar alles in een database geknald word

Dan vraag je toch niet om enters weergeven Maar goed, dan zal minq opzoek zijn naar EOL's
tip daarvoor, gebruik gewoon altijd \r\n, werkt op elk OS goed.

 | FOK! Schrikkelbaasch

dinsdag 26 augustus 2008 @ 16:24:24 #102

slacker_nl

Sicko pur sang

quote:
Op dinsdag 26 augustus 2008 16:21 schreef Swetsenegger het volgende:

[..]

Dan vraag je toch niet om enters weergeven Maar goed, dan zal minq opzoek zijn naar EOL's
tip daarvoor, gebruik gewoon altijd \r\n, werkt op elk OS goed.

Nee hoor. Daarom heb ik dos2unix tools nodig om die ^M characters weg te halen uit files die vanuit Windows aangemaakt worden....

In theory there is no difference between theory and practice. In practice there is.

FOK!-Schrikkelbaas dinsdag 26 augustus 2008 @ 16:25:55 #103

Swetsenegger

Egocentrische Narcist

Mijn windows aangemaakte PHP's werken prima op een OSX php installatie en op een linux installatie. Inclusief \r\n

 | FOK! Schrikkelbaasch

dinsdag 26 augustus 2008 @ 16:31:57 #104

CraZaay

prettig gestoord

quote:
Op dinsdag 26 augustus 2008 16:25 schreef Swetsenegger het volgende:
Mijn windows aangemaakte PHP's werken prima op een OSX php installatie en op een linux installatie. Inclusief \r\n

Hier ook. De meeste webservers gebruiken Linux, ken niemand met Windows die voor ieder bestand voor 'ie het gaat uploaden de regeleindes moet converteren.

FOK!-Schrikkelbaas dinsdag 26 augustus 2008 @ 16:37:35 #105

Swetsenegger

Egocentrische Narcist

quote:
Op dinsdag 26 augustus 2008 16:31 schreef CraZaay het volgende:

[..]

Hier ook. De meeste webservers gebruiken Linux, ken niemand met Windows die voor ieder bestand voor 'ie het gaat uploaden de regeleindes moet converteren.

Nee klopt, ook in mailbody's en dergelijke gebruik ik gewoon \r\n en dat gaat altijd goed, ook als die mail op een OSX systeem binnen komt. Ik heb die tip ook ergens van een developper site getrokken. Zo van, de quick & dirty methode is gewoon altijd \r\n gebruiken dat werkt prima op elk OS. Tot op heden ben ik er geen probleem mee tegen gekomen, en ik ontwikkel altijd door elkaar op windows en OSX.

 | FOK! Schrikkelbaasch

dinsdag 26 augustus 2008 @ 16:41:35 #106

slacker_nl

Sicko pur sang

quote:
Op dinsdag 26 augustus 2008 16:31 schreef CraZaay het volgende:

[..]

Hier ook. De meeste webservers gebruiken Linux, ken niemand met Windows die voor ieder bestand voor 'ie het gaat uploaden de regeleindes moet converteren.

Uploaden met FTP in ASCII mode.

[ Bericht 0% gewijzigd door slacker_nl op 26-08-2008 16:52:42 (format => mode..) ]

In theory there is no difference between theory and practice. In practice there is.

dinsdag 26 augustus 2008 @ 16:51:24 #107

CraZaay

prettig gestoord

Ik gebruik inderdaad ook altijd \r\n.

dinsdag 26 augustus 2008 @ 17:29:54 #108

Xcalibur

Zinloze discussie over het weergeven van linebreaks zeg

@Swets: waarom wil je die dingen in je database zetten? Waarom sla je niet gewoon de locatie van het bestand op?

dinsdag 26 augustus 2008 @ 17:59:25 #109

JortK

Immer kwaliteitsposts

quote:
Op dinsdag 26 augustus 2008 17:29 schreef Xcalibur het volgende:
Zinloze discussie over het weergeven van linebreaks zeg

@Swets: waarom wil je die dingen in je database zetten? Waarom sla je niet gewoon de locatie van het bestand op?

Dan is het niet meer portable denk ik

En je zit niet met rechten problemen

Overzicht van alle maandcijfers van het fokforum, voor de stats freaks!
Een goede Fok!search met de kracht van Google!

FOK!-Schrikkelbaas dinsdag 26 augustus 2008 @ 18:18:07 #110

Swetsenegger

Egocentrische Narcist

quote:
Op dinsdag 26 augustus 2008 17:29 schreef Xcalibur het volgende:
Zinloze discussie over het weergeven van linebreaks zeg

@Swets: waarom wil je die dingen in je database zetten? Waarom sla je niet gewoon de locatie van het bestand op?

OMdat ze al fysiek op een locatie staan van gemapte schijven en die locatie kan wijzigen. Om ze nu op een andere server weer fysiek weg te zetten is niet handig, dus vandaar in een blob. Maar ik ga wel eens kijken of het anders kan

 | FOK! Schrikkelbaasch

dinsdag 26 augustus 2008 @ 18:38:18 #111

SuperRembo

Sinds 1998

@Swetsenegger
Ik weet niet wat je nu voor "oplossing" hebt, maar addslashes() is als je met MSSql werkt so wie so zinloos. (In MSSql moet je een ' niet escapen met een \ maar met een '). M<et base64 omzelf je dat, maar efficient is 't zeker niet.

FOK!-Schrikkelbaas dinsdag 26 augustus 2008 @ 19:50:27 #112

Swetsenegger

Egocentrische Narcist

quote:
Op dinsdag 26 augustus 2008 18:38 schreef SuperRembo het volgende:
@Swetsenegger
Ik weet niet wat je nu voor "oplossing" hebt, maar addslashes() is als je met MSSql werkt so wie so zinloos. (In MSSql moet je een ' niet escapen met een \ maar met een '). M<et base64 omzelf je dat, maar efficient is 't zeker niet.

Het gaat mis met bijzondere tekens. Ik heb al gevonden op internet dat dat een bug lijkt te zijn in php 4.x Ik heb dus vandaag de server geupdate morgen even kijken of het nu wel werkt. Zo niet, ga ik toch kijken of ik relatief naar filesystem kan linken.

 | FOK! Schrikkelbaasch

dinsdag 26 augustus 2008 @ 20:08:15 #113

CraZaay

prettig gestoord

quote:
Op dinsdag 26 augustus 2008 18:38 schreef SuperRembo het volgende:

(In MSSql moet je een ' niet escapen met een \ maar met een ').

In MySQL eigenlijk stiekem ook toch, ook al gebruikt iedereen backslashes?

dinsdag 26 augustus 2008 @ 20:39:35 #114

SuperRembo

Sinds 1998

quote:
Op dinsdag 26 augustus 2008 20:08 schreef CraZaay het volgende:

[..]

In MySQL eigenlijk stiekem ook toch, ook al gebruikt iedereen backslashes?

Dat wist ik niet, maar het werkt inderdaad op beide manieren.

dinsdag 26 augustus 2008 @ 20:44:18 #115

CraZaay

prettig gestoord

Ben nu bezig met Shindig, erg leuk. Zelf Google Gadgets draaien

dinsdag 26 augustus 2008 @ 23:23:20 #116

ursel

"Het Is Hier Fantastisch!

Is er trouwens iemand een beetje bekend met Smarty, of heeft iemand anders een verklaring voor het volgende:

De klant logt in op de test-site. Alles werkt goed qua lay-out. Echter, als hij naar het beheer van de site gaat zou hij een lijst moeten zijn met alle pagina's die er zijn. Maar dat ziet hij dus niet.

Heb voor gemak even snel in een table geknalt om verder te testen en deze table een border gegeven. Dat ziet hij allemaal, echter de desbetreffende tekst en lijst met alle pagina's niet.

Hij ziet dus alleen een lege table en wel de borders van deze table.

Log ik nu in op de site met zijn inlog gegevens, dan zie ik wel alles gewoon..

Het ligt dus niet aan het user profiel.

Nu weet ik wel dat hij op een wat ouderen IE draait (IE6 en Win 2000), maar dat kan toch geen reden van dit probleem zijn??

dinsdag 26 augustus 2008 @ 23:32:42 #118

slakkie

En wat als die gast de page source opvraagt?

En kan je niet IE6 installen op je eigen machine (of via een virtual machine) om dat iig na te kijken..

dinsdag 26 augustus 2008 @ 23:56:03 #119

frenchfries

http://tredosoft.com/Multiple_IE is daar handig voor.

Wat je kan doen is vragen of hij de bron van de pagina een keer door wil sturen, als die gewoon overeen komt met die die jij hebt, ligt het in ieder geval aan een verschil aan de client-side.

woensdag 27 augustus 2008 @ 08:16:18 #120

CraZaay

prettig gestoord

Vandaar dat je ook zelf de mogelijkheid moet hebben om op alle bekende browsers te testen. Hoe kun je nou iets ontwikkelen als je het niet kunt testen op IE6

woensdag 27 augustus 2008 @ 08:27:19 #121

Xcalibur

quote:
Op dinsdag 26 augustus 2008 18:18 schreef Swetsenegger het volgende:
OMdat ze al fysiek op een locatie staan van gemapte schijven en die locatie kan wijzigen. Om ze nu op een andere server weer fysiek weg te zetten is niet handig, dus vandaar in een blob. Maar ik ga wel eens kijken of het anders kan

Kan je dan niet beter het pad naar de schijf in de config zetten ofzo?
Zodat je die alleen hoeft te wijzigen als het nodig is, of wisselt het te onvoorspelbaar daarvoor?

@ursel: lijkt me geen Smarty probleem, maar gewoon HTML

Ik heb hetzelfde probleem gehad met een LI met floatende elementen erin, waarbij ik van de UL een Scriptaculous Sortable had gemaakt (javascript dus). Daar viel ineens de content van de spans weg in IE6. FF2/3 en IE7 was niks aan de hand

woensdag 27 augustus 2008 @ 09:16:36 #122

ursel

"Het Is Hier Fantastisch!

quote:
Op dinsdag 26 augustus 2008 23:56 schreef frenchfries het volgende:
http://tredosoft.com/Multiple_IE is daar handig voor.

Wat je kan doen is vragen of hij de bron van de pagina een keer door wil sturen, als die gewoon overeen komt met die die jij hebt, ligt het in ieder geval aan een verschil aan de client-side.

Vergeten te melden dat ik dat geinstalleerd heb en ermee getest..

Desalniettemin als je hem opent als IE 5.5 bijv. en naar de properties kijkt geeft die nog wel aan dat het 7.0 is. Dacht dat het mogelijk een soort van 5.5 was.

Daarnaast is het probleem alleen in het beheer gedeeltes en ziet hij de items bij de overzicht pagina;s niet. Alle andere pagina;s werken wel gewoon goed..

woensdag 27 augustus 2008 @ 09:18:56 #123

CraZaay

prettig gestoord

Die IE's naast elkaar draaien is altijd tricky; je weet eigenlijk nooit of het nou echt goed is. Het beste is gewoon meerdere virtual machines ofzo en daar verschillende Windows instances in draaien met ieder hun eigen IE.

woensdag 27 augustus 2008 @ 09:22:35 #124

ursel

"Het Is Hier Fantastisch!

quote:
Op woensdag 27 augustus 2008 08:27 schreef Xcalibur het volgende:

[..]

Kan je dan niet beter het pad naar de schijf in de config zetten ofzo?
Zodat je die alleen hoeft te wijzigen als het nodig is, of wisselt het te onvoorspelbaar daarvoor?

Gevaar hierbij is wel dat als je een kopie van de DB verplaatst naar je andere omgeving dat je dan niet moet vergeten dit ook aan te passen mocht de 2 locaties niet identiek zijn.

quote:
@ursel: lijkt me geen Smarty probleem, maar gewoon HTML

Ik heb hetzelfde probleem gehad met een LI met floatende elementen erin, waarbij ik van de UL een Scriptaculous Sortable had gemaakt (javascript dus). Daar viel ineens de content van de spans weg in IE6. FF2/3 en IE7 was niks aan de hand

Mja, daarom snap ik het ook niet..

Gezien het bij mij en iedere andere die het getest heeft wel werkt moet het idd wel gewoon aan de client kant zitten. Maarja, hoe dan te fixen of het euvel uberhaupt vinden..

Ga denk ik wel ff bij klantje maar langs dan.

woensdag 27 augustus 2008 @ 19:10:50 #125

Mirel

Mirel wil een bongophone.

Ik heb een textbox waarbij ik wil dat je alleen 1 t/m 31 in kan vullen. Het maximum aantal cijfers dat je in kan tikken staat dan ook op 2.

Hoe kan ik dat maken met een if else statement in de action.php? Het is neem ik aan met de string $_POST['dag']; die je dan in de statement moet zetten of niet?

When all else fails, you always have delusion.

woensdag 27 augustus 2008 @ 19:26:20 #126

HuHu

1
2
3
4
5
6
7
8

<?php
$getal = (int)$_POST['dag'];
if ($dag >= 1 && $dag <= 31) {
// De dag is goed
} else {
// De dag is niet goed
}
?>

Je kunt dit ook in de HTML al een beetje doen door de gebruiker geen tekstveld te geven die hij kan invullen, maar een drop-down box waarin alleen de getallen 1 t/m 31 staan. Dat is alleen niet genoeg, maar voorkomt wel fouten.

woensdag 27 augustus 2008 @ 21:05:08 #127

Chandler

Iemand een idee hoe ik het volgende simpel kan realiseren?

Stel ik heb een array
$arr = array(1 => 20, 2 => 32, 3 => 12, 4 => 40, 5 => 25, 6 => 75);

en ik wil dit zo in een string krijgen
[1, 29], [2, 32], [3, 12], [4, 40], [5, 25], [6, 75]

want nu doe ik het zo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
function toJsArray($arr)
{
    $num = count($arr);
    $str = "";
    $x = 0;

    foreach ($arr AS $id => $key)
    {
        $x++;

        $str .= "[" . $id . "," . $key . "]" . (($x < $num) ? "," : "");
    }

    return $str;
}
?>

[ Bericht 5% gewijzigd door Chandler op 27-08-2008 21:08:51 (iets vergeten :D) ]

The people who lost my respect will never get a capital letter for their name again.
Like trump...

woensdag 27 augustus 2008 @ 21:14:48 #128

Farenji

1
2
3
4
5
6
7
8
9
10
11

<?php
function toJsArray($arr) {
    $str = '';

    foreach ($arr AS $id => $key) {
        $str .= '[' . $id . ',' . $key . '],';
    }

    return substr($str, 0, -1);
}
?>

woensdag 27 augustus 2008 @ 21:27:45 #129

HuHu

Dat met die komma aan het einde kun je ook nog oplossen met een implode:

1
2
3
4
5
6
7
8
9
10

<?php
function toJsArray($arr)
{
  $result = array();
  foreach ($arr as $id => $key) {
    $result[] = '[' . $id . ',' . $key . ']';
  }
  return implode(',', $result);
}
?>

woensdag 27 augustus 2008 @ 21:50:52 #130

Chandler

Ik wist wel dat het korter kon

tnx

The people who lost my respect will never get a capital letter for their name again.
Like trump...

woensdag 27 augustus 2008 @ 23:03:32 #131

ralfie

!Yvan eht nioj

1
2
3
4
5
6
7

<?php
function toJsArray($ar)
{
foreach($ar as $k => &$it) $it="[{$k}, {$it}]";
return join(', ',$ar);
}
?>

woensdag 27 augustus 2008 @ 23:06:01 #132

SuperRembo

Sinds 1998

quote:
Op woensdag 27 augustus 2008 21:05 schreef Chandler het volgende:
Iemand een idee hoe ik het volgende simpel kan realiseren?

Stel ik heb een array
$arr = array(1 => 20, 2 => 32, 3 => 12, 4 => 40, 5 => 25, 6 => 75);

en ik wil dit zo in een string krijgen
[1, 29], [2, 32], [3, 12], [4, 40], [5, 25], [6, 75]

Ik weet niet wat je van plan bent, maar als het de bedoeling is om die array in javascript te gebruiken kan json_encode() erg handig zijn.

donderdag 28 augustus 2008 @ 00:37:21 #133

Light

quote:
Op woensdag 27 augustus 2008 19:26 schreef HuHu het volgende:

[ code verwijderd ]

Je kunt dit ook in de HTML al een beetje doen door de gebruiker geen tekstveld te geven die hij kan invullen, maar een drop-down box waarin alleen de getallen 1 t/m 31 staan. Dat is alleen niet genoeg, maar voorkomt wel fouten.

Ik zou wel
$getal = (int)$_POST['dag'];
vervangen door
$dag = (int)$_POST['dag'];

Past iets beter bij de rest van de code

fokstok.nl

donderdag 28 augustus 2008 @ 01:51:52 #134

slakkie

quote:
Op woensdag 27 augustus 2008 19:26 schreef HuHu het volgende:

[ code verwijderd ]

en een is_numeric() test erbij gooien zodat je geen warnings krijgt op je int conversie.. en dus de user kan teruggooien naar je input scherm ofzo.

donderdag 28 augustus 2008 @ 09:00:46 #135

Xcalibur

quote:
Op woensdag 27 augustus 2008 21:05 schreef Chandler het volgende:
Iemand een idee hoe ik het volgende simpel kan realiseren?

Stel ik heb een array
$arr = array(1 => 20, 2 => 32, 3 => 12, 4 => 40, 5 => 25, 6 => 75);

en ik wil dit zo in een string krijgen
[1, 29], [2, 32], [3, 12], [4, 40], [5, 25], [6, 75]

want nu doe ik het zo:
[ code verwijderd ]

Ik vind het overigens erg verwarrend dat de value in je foreach key noemt, in plaats van de key

donderdag 28 augustus 2008 @ 10:55:52 #136

Light

quote:
Op donderdag 28 augustus 2008 01:51 schreef slakkie het volgende:

[..]

en een is_numeric() test erbij gooien zodat je geen warnings krijgt op je int conversie.. en dus de user kan teruggooien naar je input scherm ofzo.

Of gewoon intval() gebruiken.

fokstok.nl

donderdag 28 augustus 2008 @ 19:49:59 #137

Xcalibur

quote:
Op donderdag 21 augustus 2008 21:16 schreef Xcalibur het volgende:
ik probeer PostgreSQL te installeren, maar m'n PHP begrijpt het niet

PostgreSQL draait op zich prima, ik heb de bijbehorende DLL in m'n extensionmap staan, maar als ik de regel in php.ini uitcomment krijg ik de melding "Unable to load dynamic library". Ik weet zeker dat het pad goed is, bovendien heb ik geexpirimenteerd met verschillende versies van het bestand wat me verschillende foutmeldingen heeft opgeleverd...

Mis ik een ander bestand? Moet ik een bepaalde versie hebben? Moet er nog iets in m'n php.ini gebeuren?

Schopje.
Dit werkt nog steeds niet?

donderdag 28 augustus 2008 @ 19:52:43 #138

GlowMouse

l'état, c'est moi

quote:
Op donderdag 28 augustus 2008 19:49 schreef Xcalibur het volgende:

[..]

Schopje.
Dit werkt nog steeds niet?

Onder Windows neem ik aan, staat het path goed?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

donderdag 28 augustus 2008 @ 19:58:25 #139

Xcalibur

Onder windows ja.

Je bedoelt het path naar de extensions dir, die staat goed

Als ik de .dll vervang door andere versies krijg ik ook andere foutmeldingen...

Andere extensions werken ook naar behoren overigens

donderdag 28 augustus 2008 @ 20:00:49 #140

GlowMouse

l'état, c'est moi

Nee, path de omgevingsvariabele. Ziehier.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

donderdag 28 augustus 2008 @ 20:29:32 #141

Xcalibur

Ah, die path. Ja, die staat ook goed

vrijdag 29 augustus 2008 @ 09:15:49 #142

Chandler

quote:
Op donderdag 28 augustus 2008 09:00 schreef Xcalibur het volgende:
Ik vind het overigens erg verwarrend dat de value in je foreach key noemt, in plaats van de key

Het mag dan wat verwarrend zijn, maar hoe je het ook noemt het gaat om de output

Maar $id => $content zou beter zijn

The people who lost my respect will never get a capital letter for their name again.
Like trump...

vrijdag 29 augustus 2008 @ 09:27:14 #143

HuHu

quote:
Op donderdag 21 augustus 2008 19:04 schreef HuHu het volgende:
Weet iemand of het mogelijk is met MySQL middels een TRIGGER een INSERT te voorkomen?

Dus iets als:
[ code verwijderd ]

Een DELETE bij een AFTER INSERT gaat niet, omdat de zojuist ingevoegde rij dan nog gelocked is.

Niemand die hier iets op weet? Of een andere manier om een INSERT te voorkomen middels MySQL?

vrijdag 29 augustus 2008 @ 09:32:22 #144

GlowMouse

l'état, c'est moi

quote:
Op donderdag 28 augustus 2008 20:29 schreef Xcalibur het volgende:
Ah, die path. Ja, die staat ook goed

$_ENV['path'] toont dat ook (staat hier op oa. d:\program files (x86)\php)? Dat is een van de weinige dingen die fout kan gaan. Hier draait postgresql prima onder de php-5.2.5 win32 binary.

HuHu: http://www.brokenbuild.co(...)lete-with-a-trigger/

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

vrijdag 29 augustus 2008 @ 09:41:15 #145

HuHu

quote:
Op vrijdag 29 augustus 2008 09:32 schreef GlowMouse het volgende:

[..]

$_ENV['path'] toont dat ook (staat hier op oa. d:\program files (x86)\php)? Dat is een van de weinige dingen die fout kan gaan. Hier draait postgresql prima onder de php-5.2.5 win32 binary.

HuHu: http://www.brokenbuild.co(...)lete-with-a-trigger/

Hoe heb je die zo snel gevonden... ik kon niets vinden met Google. Zat waarschijnlijk weer op de verkeerde woorden te zoeken

.

Maar het is wel een beetje vieze manier, er is dus blijkbaar geen nette oplossing. Zelf had ik het nu al opgelost door ongeldige waarden in een kolom te stoppen, waardoor er een error optrad die vervolgens werd genegeerd. Eens kijken of deze manier geen error oplevert, dat is dan wel beter

.

vrijdag 29 augustus 2008 @ 09:43:58 #146

GlowMouse

l'état, c'est moi

quote:
Op vrijdag 29 augustus 2008 09:41 schreef HuHu het volgende:

[..]

Hoe heb je die zo snel gevonden... ik kon niets vinden met Google. Zat waarschijnlijk weer op de verkeerde woorden te zoeken .

Maar het is wel een beetje vieze manier, er is dus blijkbaar geen nette oplossing. Zelf had ik het nu al opgelost door ongeldige waarden in een kolom te stoppen, waardoor er een error optrad die vervolgens werd genegeerd. Eens kijken of deze manier geen error oplevert, dat is dan wel beter .

http://www.google.nl/search?hl=nl&safe=off&q=mysql+abort+insert&btnG=Zoeken&meta=

Hier zal ook wel een error door komen.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

vrijdag 29 augustus 2008 @ 10:19:52 #147

Xcalibur

quote:
Op vrijdag 29 augustus 2008 09:32 schreef GlowMouse het volgende:

[..]

$_ENV['path'] toont dat ook (staat hier op oa. d:\program files (x86)\php)? Dat is een van de weinige dingen die fout kan gaan. Hier draait postgresql prima onder de php-5.2.5 win32 binary.

Ja:

Path
C:\Program Files\PHP;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Common Files\Adobe\AGL;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\

Ik draai PHP 5.2.6, maar dat lijkt me niet zo'n probleem verder

Ik heb echt geen idee waar het aan kan liggen....

zaterdag 30 augustus 2008 @ 10:04:56 #148

Chandler

Ik ben bezig met het optimaliseren van database tabellen, maar loop tegen het volgende aan:

mijn query:

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT fish.id,
               fish.user_id,
               fish.catchdate,
               fish_categories.name,
               users.username,
               media.id AS photo_id
        FROM fish
        LEFT JOIN users ON users.id = fish.user_id
        LEFT JOIN media ON media.source_id = fish.id
        LEFT JOIN fish_categories ON fish_categories.id = fish.fish_id
        GROUP BY fish.id
        ORDER BY fish.id DESC
        LIMIT 0,4

EXPLAIN:

1
2
3
4

1 SIMPLE fish ALL NULL NULL NULL NULL 76 Using temporary; Using filesort
1 SIMPLE users ref id id 4 nl_visfreaks.fish.user_id 2
1 SIMPLE media ALL NULL NULL NULL NULL 135
1 SIMPLE fish_categories ref id id 4 nl_visfreaks.fish.fish_id 8

Het probleem is dat ik nu op de tabel FISH een filesort heb bij deze zoekactie, en dat schiet niet echt op. Nu wil ik indexes maken voor dit tabel en heb dus (fish_id, user_id en id) geindexeerd maar nog krijg ik deze filesort... weet iemand wat ik fout doe? :D

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 10:23:30 #149

Farenji

Waarom heb je in je fish tabel zowel een id veld als een fish_id veld?

zaterdag 30 augustus 2008 @ 10:27:58 #150

GlowMouse

l'état, c'est moi

Die index deugt niet. Hij staat gewoon op wat velden zonder rekeling te houden met je query. Fish_id is nergens constant, dus wordt de rest van je index niet benut. Ik snap ook niet waarom je dat indexeert: het staat weliswaar in een WHERE, maar je hebt toch altijd alle waarden van fish_id nodig, dus dat heeft geen zin (tenzij je een covering index kunt maken, maar dan weet je wel wat je doet hopelijk).
Wat hier het beste is, is een index op fish.id, een op users.id, een op media.source_id en een op fish_categories.id.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:01:19 #151

Chandler

Alle .id's zijn geindexeerd (tenminste qua opzet).

fish_id is het type vis, beetje stomme noemer, zal deze tzt overal renamen qua type!

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:08:08 #152

GlowMouse

l'état, c'est moi

Als alle genoemde velden geïndexeerd staan, kan het nog zijn dat MySQL denkt weinig voordeel te halen bij een index. Je kunt dan FORCE INDEX gebruiken op de indices die ik noemde. Met name door de LIMIT denk ik dat je daar veel voordeel door haalt op de fish-tabel (4 rijen ophalen ipv allemaal).
Bij media zou ik verwachten dat MySQL de index wel uit zichzelf benut.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:28:02 #153

Chandler

Dat had ik idd ook verwacht maar helaas, ook heb ik net geprobeerd om alle _id's te indexeren maar dat resulteerde ook niet in een snellere site... het tegenovergestelde zelfs

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:30:08 #154

GlowMouse

l'état, c'est moi

Zeg eens welke velden nu allemaal geïndexeerd staan (of beter, geef je CREATE TABLE query), en toon EXPLAIN eens met die FORCE INDEX.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:35:47 #155

Chandler

Ik heb even een create table dump gemaakt:
http://www.bruggema.nl/tables.sql

Dit zijn alle tabellen die gebruikt worden.

Force index snap ik nog niet geheel, ben de documentatie nog aan het doorspitten

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:40:29 #156

GlowMouse

l'état, c'est moi

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT fish.id,
               fish.user_id,
               fish.catchdate,
               fish_categories.name,
               users.username,
               media.id AS photo_id
        FROM fish FORCE INDEX(id)
        LEFT JOIN users ON users.id = fish.user_id
        LEFT JOIN media ON media.source_id = fish.id
        LEFT JOIN fish_categories ON fish_categories.id = fish.fish_id
        GROUP BY fish.id
        ORDER BY fish.id DESC
        LIMIT 0,4

En zoveel keys zijn het nog niet. Inserts/updates gaan wel wat trager nu, dus als je relatief veel inserts of updates hebt, moet je het aantal indices tot een minimum beperken. En indices die je helemaal niet gebruikt kun je sowieso beter helemaal weglaten.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:42:48 #157

Chandler

Nu heb ik die query gedaan en kreeg opeens te zien dat na het weghalen van de FORCE het opeens geen filesystem meer gebruikt als sorteer optie!? hoe kan dat?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:47:02 #158

GlowMouse

l'état, c'est moi

Filesort hoeft niet van het filesystem gebruik te maken hoor. En hoe het kan? Indices stonden net toch verkeerd, of heb je een analyze table gedaan?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 11:56:44 #159

Chandler

ik had niets aangepast, maar blijkbaar had MySQL zelf even de indexes aangemaakt oid.

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 11:58:40 #160

GlowMouse

l'état, c'est moi

Is dat even makkelijk

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zaterdag 30 augustus 2008 @ 12:00:49 #161

Chandler

Maar toch is de site nog sloom, maar goed; dan heb ik weer wat te doen.

-edit-doethetal

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zaterdag 30 augustus 2008 @ 12:02:07 #162

GlowMouse

l'état, c'est moi

Laat hij standaard gewoon zien. Maar ik zou er een scriptje voor maken. Voeg dan wel SQL_NO_CACHE toe aan je query, anders zul je zien dat de meest complexe queries anders in no-time worden uitgevoerd. En houd er ook rekening mee dat tabellen op een gegeven moment in het geheugen zitten, en het dan een stuk sneller gaat dan wanneer iemand je site bezoekt wanneer die tabel niet meer in het geheugen zit.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zondag 31 augustus 2008 @ 21:40:54 #163

Chandler

Nu we toch bezig zijn met indexes, heb ik het volgende; dit heb ik ergens gelezen op het internet en wilde eens weten of dit klopt

Stel je hebt een tabel waarin je personen zet.
voornaam,
achternaam
leeftijd,
woonplaats

en nu heb je op deze tabel heel veel queries draaien, maar je wilt zorgen dat dit alles snel gaat. De meeste queries zoeken op voornaam, achternaam en of woonplaats.

Dan moest je volgens het artikel de volgorde van je INDEXES volgen (bij gecombineerde indexes).
voorbeeld INDEX (voornaam, achternaam, woonplaats)

Volgens het artikel waren de volgende zoek mogelijkheden mogelijk:
SELECT voornaam, achternaam, leefttijd, woonplaats
FROM personen
WHERE woonplaats = 'Groningen'
AND achternaam = 'Test'
AND voornaam = 'Eric'

maar niet als je zo zocht:
SELECT voornaam, achternaam, leefttijd, woonplaats
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'
AND woonplaats = 'Groningen'

Klopt dit? zit nu niet echter een machine met MySQL en of wachtwoorden van sites

en zo ja, kan iemand dit dan eens duidelijk en zo mogelijk volledig uitleggen?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zondag 31 augustus 2008 @ 21:46:46 #164

GlowMouse

l'état, c'est moi

Nee klopt niet. Lees http://dev.mysql.com/doc/(...)-column-indexes.html eens door.

Belangrijkste is "A multiple-column index can be considered a sorted array containing values that are created by concatenating the values of the indexed columns"
Daarom werkt bij jou index zoeken op WHERE achternaam="blah" niet, maar op WHERE achternaam="blah" AND voornaam="hoi" wel. En daarom werkt het bij een OR niet zo goed, omdat hij alleen het tweede (en derde) stuk van een index gebruiken wanneer het eerste (en tweede) stuk constant is.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zondag 31 augustus 2008 @ 22:04:33 #165

Chandler

In het voorbeeld dat ik net las stond het volgende:

quote:
The name index is an index over the last_name and first_name columns. The index can be used for queries that specify values in a known range for last_name, or for both last_name and first_name. Therefore, the name index is used in the following queries

Nu zie ik dat de voorbeelden andersom moesten, dan klopt het!

nog een mooie quote:
MySQL cannot use an index if the columns do not form a leftmost prefix of the index gewoon index volgen in je where parameters beginnend van links naar rechts en eventueel meer toevoegen... ?

^{ik probeer het allemaal te begrijpen maar't gaat niet zo snel}

dus dit werkt met de index:
SELECT *
FROM personen
WHERE voornaam = 'Eric'

en

SELECT *
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'

en dus ook alle 3 en eventueel meer

SELECT *
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'
AND woonplaats = 'Groningen'
AND leeftijd < 50

maar hoe werkt het dan met dit:

SELECT *
FROM personen
WHERE voornaam = 'Eric'
AND achternaam = 'Test'
AND leeftijd < 50

zal deze dan ook de index gebruiken?

ik vraag maar hoor

The people who lost my respect will never get a capital letter for their name again.
Like trump...

zondag 31 augustus 2008 @ 22:09:42 #166

GlowMouse

l'état, c'est moi

Via voornaam en achternaam (en bij die een na laatste ook woonplaats) haalt hij de rijen op die eraan voldoen, en daarna checkt hij bij die rijen de leeftijd. Daarom is Woonplaats niet zo nuttig om in je index te zetten: tenzij je de query SELECT woonplaats FROM table WHERE voornaam='a' AND achternaam='b' heel vaak gebruikt (zodat je een covering index hebt, maar dat is alleen nuttig als je hem heel vaak gebruikt), omdat er toch niet veel rijen overblijven na selectie op voornaam en achternaam. Want onthoud: hoe langer de index, hoe meer tijd hij kost om bij te werken, en hoe meer tekstvelden in een index, hoe trager hij wordt bij een SELECT-query omdat hij dan erg groot (veel kB's) wordt.

Overigens zie je via EXPLAIN SELECT ... welk deel van de index naar verwachting benut zal worden.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

zondag 31 augustus 2008 @ 22:13:36 #167

Light

quote:
Op zondag 31 augustus 2008 22:04 schreef Chandler het volgende:
In het voorbeeld dat ik net las stond het volgende:
[..]

Nu zie ik dat de voorbeelden andersom moesten, dan klopt het!

nog een mooie quote:
MySQL cannot use an index if the columns do not form a leftmost prefix of the index gewoon index volgen in je where parameters beginnend van links naar rechter en eventueel meer toevoegen... ?

Als je een index hebt op (lastname, firstname) dan kun je queries doen als:
SELECT * FROM persons WHERE lastname="Test";
SELECT * FROM persons WHERE lastname="Test" AND firstname="Eric";
SELECT * FROM persons WHERE firstname="Eric" AND lastname="Test";
Maar niet:
SELECT * FROM persons WHERE firstname="Eric";

fokstok.nl

maandag 1 september 2008 @ 09:25:19 #168

Chandler

Duidelijk, dan zijn mijn queries toch aardig goed

en indexes ook

Een andere vraag stel ik wil het volgende opslaan.

71.231
302.121
5.1231

Wat moet ik daarvoor gebruiken? gebruik nu een char, maar dat lijkt me niet echt handig

Verder heb ik een query die best wel veel tijd neemt en heb deze met analyze geprobeerd te begrijpen:

1
2
3
4
5

EXPLAIN SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE UNIX_TIMESTAMP( stats_ip_link.lastdate ) > ( UNIX_TIMESTAMP( NOW( ) ) - ( 60 *15 ) )
GROUP BY stats_ip_link.stat_id

nu krijg ik het volgende resultaat:

1
2
3

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE stats_ip_link ALL NULL NULL NULL NULL 70168 Using where; Using temporary; Using filesort
1 SIMPLE stats_ip eq_ref PRIMARY PRIMARY 4 gfxstatcom_db.stats_ip_link.ip_id 1 Using index

nu heb ik op het tabel stats_ip_link een index op stat_id en stat_ip en een index op 'lastdate` maar nog steeds is deze sloom

Anyone?

of is het handiger dat ik lastdate en firstdate (beiden datetime) verander naar timestamp oid?

[ Bericht 33% gewijzigd door Chandler op 01-09-2008 09:44:02 ]

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 10:21:55 #169

GlowMouse

l'état, c'est moi

Die nummers kun je het beste opslaan als een mediumint (signed/unsigned, afhankelijk van of je wel/geen negatieve nummers tegenkomt).

De index op stats_ip_link is lastig: je kunt hem op lastdate zetten voor de WHERE, je kunt hem op stat_id zetten voor de GROUP BY, maar op (lastdate,stat_id) heeft het geen zin omdat lastdate niet constant is en stat_id daarna niet meer benut kan worden. Het beste lijkt mij hier een index op lastdate, omdat hoe langer je die tabel houdt, je na toepassen van de WHERE altijd ongeveer evenveel resultaten overhoudt, zodat het in de loop der tijd niet langzamer wordt.
Die index moet wel benut kunnen worden, en als je een functie op een kolom loslaat, kan dat niet meer. Zelf werk ik altijd met unix timestamps in een database, maar jouw aanpak moet ook kunnen werken. Kun je niet iets doen als lastdate > mysqls datetime formaat van 15 minuten geleden?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:06:14 #170

Chandler

Ook een index op lastdate werkt niet qua snelheid bevordelijk!

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:07:52 #171

GlowMouse

l'état, c'est moi

Dat is gek, welke query gebruik je nu, en hoeveel rijen voldoen er aan WHERE UNIX_TIMESTAMP( stats_ip_link.lastdate ) > ( UNIX_TIMESTAMP( NOW( ) ) - ( 60 *15 ) ) ?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:23:10 #172

Chandler

80 rijen maar dit kan per seconde veranderen

en de query die ik eerder ook al gepost heb

1
2
3
4
5

SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE UNIX_TIMESTAMP( stats_ip_link.lastdate ) > ( UNIX_TIMESTAMP( NOW( ) ) - ( 60 *15 ) )
GROUP BY stats_ip_link.stat_

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:32:26 #173

GlowMouse

l'état, c'est moi

Met 80 zou hij heel snel moeten zijn. Moet je wel dit in acht nemen:

quote:
Die index moet wel benut kunnen worden, en als je een functie op een kolom loslaat, kan dat niet meer. Zelf werk ik altijd met unix timestamps in een database, maar jouw aanpak moet ook kunnen werken. Kun je niet iets doen als lastdate > mysqls datetime formaat van 15 minuten geleden?

En die query moet ook wachten als de tabel geüpdatet wordt, dus dat kan wel wat traagheid veroorzaken, maar met een rij of 80 is het anders heel snel als die index benut kan worden.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:38:41 #174

Chandler

Zou ik ook zeggen maar helaas

het blijft toch sloom

Er staan ruim 70.000 items in dit tabel, waarbij lastdate geindexeerd is!. Je zou denken dat de server dit binnen 0.01 seconde zou moeten kunnen uitzoeken maar helaas, dat doet het niet

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:41:09 #175

GlowMouse

l'état, c'est moi

Hoe ziet je query er dan nu uit?

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:42:47 #176

Chandler

Bedoel je met explain of zonder explain? zonder is de zelfde als bovenstaande

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:43:22 #177

GlowMouse

l'état, c'est moi

Ik quote mezelf toch niet voor niks? f(kolom) kan niet geïndexeerd worden, dus moet je je query aanpassen.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 11:45:57 #178

Chandler

Ik snap je niet helemaal (probeer het wel hoor

)

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 11:48:09 #179

GlowMouse

l'état, c'est moi

Je query moet in deze vorm staan:

1
2
3
4
5

SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE stats_ip_link.lastdate > .......
GROUP BY stats_ip_link.stat_id

MySQL is niet slim genoeg om in te zien dat UNIX_TIMESTAMP een monotone functie is.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:18:50 #180

Chandler

Ik zie idd dat de snelheid bepaald wordt door unix_timestamp

1
2
3
4
5

SELECT stats_ip_link.stat_id, count( stats_ip.id ) AS count
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE stats_ip_link.lastdate > ( NOW( ) - ( 60 *15 ) )
GROUP BY stats_ip_link.stat_id

deze query duurde 0.022 terwijl deze (vorige) ruim 0.7xxx aan tijd nam.

Echter verschillen beide queries qua uitkomst :{

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 12:20:17 #181

GlowMouse

l'état, c'est moi

Dan kijk je naar de output van

1
2
3
4

SELECT *
FROM stats_ip_link
LEFT JOIN stats_ip ON stats_ip.id = stats_ip_link.ip_id
WHERE stats_ip_link.lastdate > ( NOW( ) - ( 60 *15 ) )

en kijk je welke rijen er tussenstaan die er niet tussen zouden moeten staan.

Je ziet zelf al wat er fout gaat met deze query: SELECT NOW( ) , NOW( ) -15 *60

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:24:47 #182

Chandler

Ik zie het idd!

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 12:26:56 #183

GlowMouse

l'état, c'est moi

Doe eens deze query: SELECT NOW(), NOW( ) -15 *60, SUBTIME(NOW(),'0 0:15:0');
Dan zou je genoeg moeten weten

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:29:42 #184

Chandler

Super!!! dat scheelt per query zo'n 0.7xxx seconden!!!

Maar is het in mijn geval niet handiger om gewoon de timestamp op te slaan?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 12:31:32 #185

GlowMouse

l'état, c'est moi

Kwestie van voorkeur

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 12:46:31 #186

Chandler

Zou het geen preformance verschil (op de lange duur) met zich mee brengen? en het scheelt volgens mij ook in de grootte die het op de schijf neemt

quote:
TIMESTAMP requires 4 bytes.
DATETIME requires 8 bytes.

http://bitfilm.net/2007/08/25/choosing-optimal-mysql-data-types/

en ik denk dat timestamps gemakkelijker te indexeren zijn (denk ik)

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 13:03:04 #187

GlowMouse

l'état, c'est moi

Je index wordt de helft kleiner, dus het zal wel wat schelen. Maar dat verschil is heel klein, en wordt nauwelijks groter. Een TIMESTAMP zal op termijn (zeker in 20-30 jaar) trouwens ook naar 8 bytes gaan omdat je anders geen datums na 2037 op kunt slaan.

eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0

maandag 1 september 2008 @ 14:37:30 #188

Nevermind

(-_-)

Ik wil in mijn .htaccess alles matchen, behalve afbeeldingen. Ik wil alle afhandeling van de querystring overlaten aan php. Dus:

http://domein.nl/blaat/bla/bla/bla -> index.php?querystring=blaat/bla/bla/bla
http://domein.nl/hoi.html -> index.php?querystring=hoi.html
http://domein.nl/plaatje.png -> geen match

Dat houdt in dat ook slashes gematcht moeten worden in de RewriteRule, en dat krijg ik niet werkend.

1
2
3
4
5

RewriteEngine On
RewriteBase /project

RewriteCond %{REQUEST_FILENAME} \.^(gif|jpe?g|png)$ [NC]
RewriteRule ^([A-Za-z0-9-\-.\/]+)$ index.php?input=$1

Ik zie iets over het hoofd. Afbeeldingen worden wel weergegeven, iets willekeurigs invullen als url geeft een 404.

GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!

maandag 1 september 2008 @ 15:09:07 #189

slakkie

Nevermind, dat heeft heul niks met php of mysql te maken.

maandag 1 september 2008 @ 15:33:48 #190

Nevermind

(-_-)

True, maar een nieuw topic openen voor zo'n kleine vraag is ook loos. Lijkt me dat hier veel mensen zijn die het antwoord wel weten

GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!

maandag 1 september 2008 @ 17:11:25 #191

slakkie

Jongens, maak je een for-loop in perl? Simpele vraag, kunnen mensen hier vast beantwoorden

maandag 1 september 2008 @ 18:42:18 #192

Chandler

Nog een vraagje, ik wil 2 timestamps gebruiken in 1 tabel, echter krijg ik dit niet voor elkaar.. Error in de zin van dubbele CURRENT_TIME oid. Hoe los ik dit op? of moet ik gewoon INT gebruiken?

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 18:45:16 #193

Xcalibur

Je kunt geen twee timestamps in 1 tabel gebruiken... in ieder geval geen timestamps die automatisch geupdate worden iig. Erg irritant, ik snap ook echt niet waarom dat niet kan

maandag 1 september 2008 @ 19:15:38 #194

SuperRembo

Sinds 1998

quote:
Op maandag 1 september 2008 18:45 schreef Xcalibur het volgende:
Je kunt geen twee timestamps in 1 tabel gebruiken... in ieder geval geen timestamps die automatisch geupdate worden iig.

En waarom zou je dat dan willen

maandag 1 september 2008 @ 19:47:28 #195

Xcalibur

1 voor de create datum (automatisch bij inserten) en 1 voor de laatste wijziging datum (automatisch bij updaten)

maandag 1 september 2008 @ 20:00:21 #196

Chandler

Correct, daarom wil ik 2x een timestamp hebben die niet automatisch geupdated wordt!

of een mogelijkheid dat ik 2x een timestamp kan gebruiken!

-edit-
je kunt wel twee timestamps gebruiken maar zit er een máár aan!. De eerste timestamp zal automatisch geupdated worden en de tweede niet, beetje vervelend

http://michaelkimsal.com/(...)eatedupdated-values/

nu is de vraag wat moet ik gebruiken om een alternatieve manier voor timestamp in te kunnen voeren?

[ Bericht 22% gewijzigd door Chandler op 01-09-2008 20:09:26 ]

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 20:14:59 #197

SuperRembo

Sinds 1998

Kan dit dan niet tegelijk in 1 tabel?

1 2	created TIMESTAMP DEFAULT CURRENT_TIMESTAMP modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

[edit]
Dat kan dus blijkbaar niet:

quote:
MySQL said:
#1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause

Vreemd. Maar dan maak je gewoon 1 autoupdate kolom (modified) en de ceated insert je zelf. (Dat insert statement heb je uiteraard maar op 1 plaats staan, dus dat pas je ze aan

)

[ Bericht 38% gewijzigd door SuperRembo op 01-09-2008 20:37:13 ]

maandag 1 september 2008 @ 20:16:29 #198

Chandler

Nee, de eerste moet de modified zijn en de 2e de createdate, en helaas heb ik het in mijn huidig model net andersom

The people who lost my respect will never get a capital letter for their name again.
Like trump...

maandag 1 september 2008 @ 20:17:18 #199

SuperRembo

Sinds 1998

quote:
Op maandag 1 september 2008 20:00 schreef Chandler het volgende:
je kunt wel twee timestamps gebruiken maar zit er een máár aan!. De eerste timestamp zal automatisch geupdated worden en de tweede niet, beetje vervelend

Wat is het nut van twee kolommen waar altijd dezelfde waarde in staat?

maandag 1 september 2008 @ 20:35:58 #200

Chandler

Hoezo? 1 is voor de aanmaak datum de 2e is voor de laatste update? daar is toch niets het zelfde in? tenzij een record niet geupdated wordt na aanmaak???

The people who lost my respect will never get a capital letter for their name again.
Like trump...

Forum Opties
Forumhop:
Hop naar:	(afkorting, bv 'KLB')

[PHP/(My)SQL] voor dummies - Deel 62

» digital corner

» development

» digital corner

» development