Jimmy, du verkar ha använt argumentet i fel ordning?
Enligt API så ska det vara:
esource mysql_db_query ( string database, string query [, resource link_identifier] )
men du skickar in query först och sen db.
Sen står det också i API att mysql_db_query är deprecated och att man bör använda mysql_query istället, inte för att det bör ha något med detta felet att göra.
/a
Komponent-databas och SQL
-
JimmyAndersson
- Inlägg: 26571
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
"mysql_db_query är deprecated och att man bör använda mysql_query istället, inte för att det bör ha något med detta felet att göra."
Men den ändringen löste problemet.
"Jimmy, du verkar ha använt argumentet i fel ordning?"
Ajdå, men det verkar fungera ändå, konstigt nog. Har sett samma bakvända ordning i flera exempel-koder. Här t.ex.
Men den ändringen löste problemet.
"Jimmy, du verkar ha använt argumentet i fel ordning?"
Ajdå, men det verkar fungera ändå, konstigt nog. Har sett samma bakvända ordning i flera exempel-koder. Här t.ex.
-
JimmyAndersson
- Inlägg: 26571
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Mycket troligt. 
Nästa grejj blir att lägga in koden på rätt sida och fixa "radiobuttons" så att man kan välja om man ska söka på komponent, art-nr eller säljare.
Klart:
* Lista komponenter.
* Lägg till nya komponenter.
* Sök-funktionen (efter ändringarna ovan.)
Att göra:
* Kod för att kunna editera rader genom att t.ex söka på ett art-nr och få upp resultatet i text-fält som kan editeras och sparas. Man ska även kunna ta bort den komponenten.
* Fler komponentkategorier och fixa menyn för dem.
* Funktion som lägger till komponenter som håller på att ta slut i en egen lista. (En lista per säljare.) Tanken är att man enkelt ska kunna få in listorna i Excel så man bara behöver skicka dem till t.ex Elfa.
Sedan är version1 klar.
I nästa version kommer jag inkludera automatisk pakethämtning på Posten. Tror att jag såg en funktion för det i PHP-manualen..
Nästa grejj blir att lägga in koden på rätt sida och fixa "radiobuttons" så att man kan välja om man ska söka på komponent, art-nr eller säljare.
Klart:
* Lista komponenter.
* Lägg till nya komponenter.
* Sök-funktionen (efter ändringarna ovan.)
Att göra:
* Kod för att kunna editera rader genom att t.ex söka på ett art-nr och få upp resultatet i text-fält som kan editeras och sparas. Man ska även kunna ta bort den komponenten.
* Fler komponentkategorier och fixa menyn för dem.
* Funktion som lägger till komponenter som håller på att ta slut i en egen lista. (En lista per säljare.) Tanken är att man enkelt ska kunna få in listorna i Excel så man bara behöver skicka dem till t.ex Elfa.
Sedan är version1 klar.
I nästa version kommer jag inkludera automatisk pakethämtning på Posten. Tror att jag såg en funktion för det i PHP-manualen..
-
JimmyAndersson
- Inlägg: 26571
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
> Sen står det också i API att mysql_db_query är deprecated och
> att man bör använda mysql_query istället, inte för att det bör
> ha något med detta felet att göra.
Och varför skulle det inte ha något med felet att göra ?
Funktionerna har olika antal parametrar (3 resp 2) och kan inte
bara bytas ut mot varandra hur som helst (med samma parametrar).
Jimmy, det var ju längde sedan tidigare i tråden som vi var överens
om att *INTE* köra med mysql_db_query, eller hur
Sen finns det ingenting i tidigare inlägg som är i "fel ordning"...
Ni har bara blandat ihop den första parametern till mysql_db_query
("database") med sista parametern till båda funktionerna ("link_identifier").
Eftersom Jimmy har valt att kalla sin "link_identifier" för "$db", så kanske
det kan vara lätt att förväxla dom, men om man bara RTFM ordentligt, så
är det helt solklart vad som är vad...
EDIT:
Jimmy, jag har kollat koden på din länk ovan, och det finns *inget*
bakvänt där. Kolla igen får du se !
> att man bör använda mysql_query istället, inte för att det bör
> ha något med detta felet att göra.
Och varför skulle det inte ha något med felet att göra ?
Funktionerna har olika antal parametrar (3 resp 2) och kan inte
bara bytas ut mot varandra hur som helst (med samma parametrar).
Jimmy, det var ju längde sedan tidigare i tråden som vi var överens
om att *INTE* köra med mysql_db_query, eller hur
Sen finns det ingenting i tidigare inlägg som är i "fel ordning"...
Ni har bara blandat ihop den första parametern till mysql_db_query
("database") med sista parametern till båda funktionerna ("link_identifier").
Eftersom Jimmy har valt att kalla sin "link_identifier" för "$db", så kanske
det kan vara lätt att förväxla dom, men om man bara RTFM ordentligt, så
är det helt solklart vad som är vad...
EDIT:
Jimmy, jag har kollat koden på din länk ovan, och det finns *inget*
bakvänt där. Kolla igen får du se !
-
JimmyAndersson
- Inlägg: 26571
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Ah, nu fattar jag. Nä det var ju inget bakvänt där.
"Jimmy, det var ju längde sedan tidigare i tråden som vi var överens
om att *INTE* köra med mysql_db_query, eller hur"
Sant.
Jag hade kopierat lite kod från min gamla php-fil där jag inte bytt ut mysql_db_query mot mysql_query. Eftersom mysql_db_query användes på sidan jag länkade till tidigare så upptäckte jag inte missen förrän jag debuggat koden. Men det var bra att det här dök upp, för nu har skillnaderna fastnat ordentligt i hjärnan.
"Jimmy, det var ju längde sedan tidigare i tråden som vi var överens
om att *INTE* köra med mysql_db_query, eller hur"
Sant.
Jag hade kopierat lite kod från min gamla php-fil där jag inte bytt ut mysql_db_query mot mysql_query. Eftersom mysql_db_query användes på sidan jag länkade till tidigare så upptäckte jag inte missen förrän jag debuggat koden. Men det var bra att det här dök upp, för nu har skillnaderna fastnat ordentligt i hjärnan. 
Ledsen att jag inte sett den här tråden tidigare. Har ett par nyttiga tips att ge tror jag. (kanske för sent nu, men till v2.0 kanske?)
Viktigast av allt: en BRA strukturerad databas brukar lösa många problem! Att bygga om databasen EFTER att php-koden är skriven brukar sällan vara en trevlig uppgift...
För att åstakomma en bra uppbyggnad av databasen så finns det några saker att tänka på.
1. Skissa upp och "bryt ut" alla typer av "objekt" som kan existera. Med objekt så menar jag t.ex. komponenttyper och leverantörer.
2. Undvik att behöva skapa och ta bort tabeller dynamiskt (under tiden databasen används)
För ditt ändamål skulle jag skapa denna struktur med 3 tabeller:
tbl_Komponent
-index
-typ (kopplat mot "index" i tbl_komponenttyper)
-levernatör (kopplat mot index i tbl_Leverantör)
-värde
-artnr
-antal_i_lager
tbl_Leverantörer
-index
-Namn
-Adress
-tel
tbl_komponenttyper
-index
-beskrivning
-kommentar
Med mitt förlag på uppyggnad är det enklare att lägga till en ny komponent. Man behöver inte lägga till en ny tabell, det räcker med att lägga till en post i tbl_komponenttyper. Sökningar blir också lättar genom detta.
Tyvärr finns det en liten nackdel med denna uppdelning om man är "ny" när det gäller SQL-frågor, de blir nämligen lite mer komplexa eftersom man måste göra förfrågningar som innefattar mer än en tabell.
Om du kikat på min hemautomation så är den uppbyggd på ett likande sätt som förslaget ovan: En tabell för enheter (enskilda lampor), en för gruppdata och en för aktiviteter (schemat). För att binda ihop en gruppbeskrivning med en eller flera lampor så använder jag ytterligare en tabell för detta.
I ditt fall skulle en sådan referenstabell vara användbar om en specifik komponent finns hos flera leverantörer. (Binder ett komponentindex till ett eller flera levernatörsindex)
Viktigast av allt: en BRA strukturerad databas brukar lösa många problem! Att bygga om databasen EFTER att php-koden är skriven brukar sällan vara en trevlig uppgift...
För att åstakomma en bra uppbyggnad av databasen så finns det några saker att tänka på.
1. Skissa upp och "bryt ut" alla typer av "objekt" som kan existera. Med objekt så menar jag t.ex. komponenttyper och leverantörer.
2. Undvik att behöva skapa och ta bort tabeller dynamiskt (under tiden databasen används)
För ditt ändamål skulle jag skapa denna struktur med 3 tabeller:
tbl_Komponent
-index
-typ (kopplat mot "index" i tbl_komponenttyper)
-levernatör (kopplat mot index i tbl_Leverantör)
-värde
-artnr
-antal_i_lager
tbl_Leverantörer
-index
-Namn
-Adress
-tel
tbl_komponenttyper
-index
-beskrivning
-kommentar
Med mitt förlag på uppyggnad är det enklare att lägga till en ny komponent. Man behöver inte lägga till en ny tabell, det räcker med att lägga till en post i tbl_komponenttyper. Sökningar blir också lättar genom detta.
Tyvärr finns det en liten nackdel med denna uppdelning om man är "ny" när det gäller SQL-frågor, de blir nämligen lite mer komplexa eftersom man måste göra förfrågningar som innefattar mer än en tabell.
Om du kikat på min hemautomation så är den uppbyggd på ett likande sätt som förslaget ovan: En tabell för enheter (enskilda lampor), en för gruppdata och en för aktiviteter (schemat). För att binda ihop en gruppbeskrivning med en eller flera lampor så använder jag ytterligare en tabell för detta.
I ditt fall skulle en sådan referenstabell vara användbar om en specifik komponent finns hos flera leverantörer. (Binder ett komponentindex till ett eller flera levernatörsindex)
Jo det är sant, från och med version 5, som kom rätt så nyligt, så stöds vyer, lagrade procedurer och triggers. Bra bra!
Även om man använder vyer och procedurer så kräver det ju ändå att man måste skriva minst EN sql-query som använder flera tabeller.
Dessutom... vyer används väl inte för att förenkla för SQL-programmeraren, den största fördelen får ju PHP-programmeraren! (eller det språk man nu använder).
Eftersom det (troligtvis) är Jimmy som arbetar med båda sakerna så finns det inte så mycket att vinna på att använda vyer. Jag skulle tro att det bara blir krångligare att behöva sätta sig in i det också.
Även om man använder vyer och procedurer så kräver det ju ändå att man måste skriva minst EN sql-query som använder flera tabeller.
Dessutom... vyer används väl inte för att förenkla för SQL-programmeraren, den största fördelen får ju PHP-programmeraren! (eller det språk man nu använder).
Eftersom det (troligtvis) är Jimmy som arbetar med båda sakerna så finns det inte så mycket att vinna på att använda vyer. Jag skulle tro att det bara blir krångligare att behöva sätta sig in i det också.
En annan viktig sida som inte nämnts är mysql referens manual. Jag tyckte det var ganska informativt att läsa hela kapitel 3 - tutorial. Tutorialet tar även upp lite grann hur man använder flera tabeller till sammans ( som ojsan föreslog ) vilket nästan är ett måste för smidigt databasanvändande. Det är inte såå långt och där får man en god inblick i det viktigaste. Sen kan du läsa kapitel 13 - Statement syntax vid behov.
Ett allmänt tips som jag inte sett getts här tidigare är att ALDRIG göra redundanta databaser, dvs spara samma information på två ställen i två olika tabeller. Om du ska updatera och glömmer att updatera överallt så kan det bli riktig pannkaka med buggar som är svåra att hitta. En annan klassiker är att inte spara data som åldras snabbt, t.ex. spara inte en persons ålder (som måste updateras varje år). Spara istället en persons födelseår, det behöver aldrig updateras och innehåller samma information.
ett annat tips är att skriva frågorna såhär
$query = "min sql fråga"
$res = myql_query($query) or die("Fel i fråga: $query")
(om mysql_query() returnerar falskt kommer die() funktionen att köras, annars inte) Eftersom frågorna ofta är ihopsatta med hjälp av massa ifsatser och ihopslagning av strängar m.m. är det i 95% av fallen (för mig iaf) det blir fel där, och då vill man att programmet skall sparka bakut på en gång och visa vad som gick fel, och inte fortsätta ner en massa rader och bete sig skumt.
Ett allmänt tips som jag inte sett getts här tidigare är att ALDRIG göra redundanta databaser, dvs spara samma information på två ställen i två olika tabeller. Om du ska updatera och glömmer att updatera överallt så kan det bli riktig pannkaka med buggar som är svåra att hitta. En annan klassiker är att inte spara data som åldras snabbt, t.ex. spara inte en persons ålder (som måste updateras varje år). Spara istället en persons födelseår, det behöver aldrig updateras och innehåller samma information.
ett annat tips är att skriva frågorna såhär
$query = "min sql fråga"
$res = myql_query($query) or die("Fel i fråga: $query")
(om mysql_query() returnerar falskt kommer die() funktionen att köras, annars inte) Eftersom frågorna ofta är ihopsatta med hjälp av massa ifsatser och ihopslagning av strängar m.m. är det i 95% av fallen (för mig iaf) det blir fel där, och då vill man att programmet skall sparka bakut på en gång och visa vad som gick fel, och inte fortsätta ner en massa rader och bete sig skumt.
-
JimmyAndersson
- Inlägg: 26571
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
oJsan: Jag är inte helt säker på att jag förstår. Men om vi tar min databas som exempel. Såhär har jag gjort:
Databas: komponentlager
tbl_motstand
-komponent (t.ex 10k, 1/2w, ytmonterat)
-antal (t.ex 23)
-art-nr (t.ex 123-456)
-saljare (t.ex Elfa)
Sedan ska det fyllas på med t.ex:
tbl_kondensator
-komponent (t.ex 10µF, 100v, radiell)
-antal (t.ex 12)
-art-nr (t.ex 234-567)
-saljare (t.ex Elfa)
"I ditt fall skulle en sådan referenstabell vara användbar om en specifik komponent finns hos flera leverantörer."
Men låt säga att det ser ut såhär:
KOMPONENT: 10k, 1/4w. ANTAL: 14. ART-NR: 123-456. SÄLJARE: Elfa
KOMPONENT: 10k, 1/4w. ANTAL: 3. ART-NR: 44-555. SALJARE: ClasOhlsson.
Då borde det väl inte göra något att samma värde finns hos flera tillverkare? Har jag t.ex köpt 50st av art-nr 123-456 så räcker det ju att söka på artikel-nummret. 44-555 börjar ju ta slut, så den komponenten läggs till i inköps-listan för ClasOhlsson.
Som sagt, jag ser inte riktigt varför den här strukturen inte fungerar, så berätta gärna mer. Än så länge har jag inte lagt in några riktiga komponent-värden, så jag har inget emot att göra om strukturen.
Databas: komponentlager
tbl_motstand
-komponent (t.ex 10k, 1/2w, ytmonterat)
-antal (t.ex 23)
-art-nr (t.ex 123-456)
-saljare (t.ex Elfa)
Sedan ska det fyllas på med t.ex:
tbl_kondensator
-komponent (t.ex 10µF, 100v, radiell)
-antal (t.ex 12)
-art-nr (t.ex 234-567)
-saljare (t.ex Elfa)
"I ditt fall skulle en sådan referenstabell vara användbar om en specifik komponent finns hos flera leverantörer."
Men låt säga att det ser ut såhär:
KOMPONENT: 10k, 1/4w. ANTAL: 14. ART-NR: 123-456. SÄLJARE: Elfa
KOMPONENT: 10k, 1/4w. ANTAL: 3. ART-NR: 44-555. SALJARE: ClasOhlsson.
Då borde det väl inte göra något att samma värde finns hos flera tillverkare? Har jag t.ex köpt 50st av art-nr 123-456 så räcker det ju att söka på artikel-nummret. 44-555 börjar ju ta slut, så den komponenten läggs till i inköps-listan för ClasOhlsson.
Som sagt, jag ser inte riktigt varför den här strukturen inte fungerar, så berätta gärna mer. Än så länge har jag inte lagt in några riktiga komponent-värden, så jag har inget emot att göra om strukturen.
I ditt fall med olika tabeller för motstånd och kondensatorer så måste man lägga till en ny tabell för varje ny komponenttyp man vill ha. Detta vill man gärna kunna göra i efterhand och är då trevligt att kunna göra utan att ändra själva tabellstrukturen utan bara innehållet.
Du gör en tabell som heter komponenter och sedan har du ett fält i den som refererar till indexet i en annan tabell, t.ex med namnet "komponenttyp" där du har en post för varje typ av komponent du vill använda. I ditt exempel endast två poster. För att lägga till en ny typ av komponenter så behöver du då bara lägga till en post i den nya typtabellen istället för att skapa en ny tabell.
När du vill ha ut data för bara en komponenttyp så gör du en "join" med typtabellen och får då ut även vilken typ varje komponent tillhör i varje post.
Du gör en tabell som heter komponenter och sedan har du ett fält i den som refererar till indexet i en annan tabell, t.ex med namnet "komponenttyp" där du har en post för varje typ av komponent du vill använda. I ditt exempel endast två poster. För att lägga till en ny typ av komponenter så behöver du då bara lägga till en post i den nya typtabellen istället för att skapa en ny tabell.
När du vill ha ut data för bara en komponenttyp så gör du en "join" med typtabellen och får då ut även vilken typ varje komponent tillhör i varje post.
-
JimmyAndersson
- Inlägg: 26571
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
