bluebird

Sveiki!

Nebija laika pie šā pieķerties, bet nu esmu atgriezies un mēģinu salabot to.

Šādi ievietojot kodā:

$raksti = array(
       'http://localhost/pakalpojums1/',
       'http://localhost/pakalpojums2/',
       'http://localhost/pakalpojums3/',
);

foreach($raksti as $raksts) {

       if($lightbox){
           $images .= '<a title="' . get_the_title($id) .'"  href="'.  $raksts /* Max upload size in WP? OR Thumb.php? -> exposure_thumb_url($full_image,920,600) */ .'"><img src="'. $img_url .'" width="'.$w.'" alt="'.get_the_title($id).'" /></a>';   
       } else {
           $images .= '<a href="'. $link .'"><img width="'.$w.'" src="'. $img_url .'" alt="'.get_the_title($id).'" /></a>';
       }
};

tiek paņemtas visas vērtības, bet tas widget tiek uzģenerēts 3x3.

Kā šī funkcija būtu jāpārveido korekti?

Pielikumā esmu pievienojis kā tiek izvadīts.

Paldies!

Esvairāk gribētu, un mani nepamet sajūta, ka labāk būtu, ka uztaisu array ar trim linkiem (bet jebkadiem nosaukumiem utt) un .. pie katra Wordpress Gadget izvades

šajā vietā

if($lightbox){
           $images .= '<a title="' . get_the_title($id) .'"  href="'.  $raksts  .'"><img src="'. $img_url .'" width="'.$w.'" alt="'.get_the_title($id).'" /></a>';   
       } 

vērtību $raksts aizstāj ar array vērtību. Ņemot katru pēc kārtas. Man nevajag nekādus nosaukumus pieprasīt vai ko vēl, jo to jau tas skripts paņem automātiski. Man tikai vajag lai paķer linku nevis to kas bija defaultā, bet to ko es norādu.

Tādēļ es domāju ka tas variants ko tu rakstīji tā īsti manā gadijumā nederēs.

Un kā man Val rakstīto iepīt skriptā kurš man ir nepieciešams.

Mēģināšu vēlreiz izskaidrot manu situāciju un kā tas viss darbojas.

Man ir Wordpress templeits kurš pirmajā lapā Widgetā izvada bildi no posta katrai bildei ir links, bet tas links kas ir uz bildes ved uz to lapu kur ir posts, BET man nepieciešams, lai viņs aizved uz Page

Tad nu lūk es atradu kurā vietā tas widget skripts atrodas un kas tieši iedot to saiti.

if($lightbox){
           $images .= '<a title="' . get_the_title($id) .'"  href="'.  $raksts /* Max upload size in WP? OR Thumb.php? -> exposure_thumb_url($full_image,920,600) */ .'"><img src="'. $img_url .'" width="'.$w.'" alt="'.get_the_title($id).'" /></a>';   
       }

Nu lūk. Mainīgais $raksts ir tas kuram es gribu iebarot saites manuāli.

Tad nu cik saprotu man ir nepieciešams sakombinēt ar šo:

$raksti = array(
       'http://localhost/pakalpojums1',
       'http://localhost/pakalpojums2',
       'http://localhost/pakalpojums3',
);
foreach($raksti as $raksts) {
       echo "<p>$raksts</p>"; //un viss pārējais par konkrēto rakstu
};

Tikai kā man to vērtību iepīt šeit:

href="'. $raksts

Tas Wordpress Widget jau darbojās pēc principa ka izvada tās bildes ar Posta nosaukumu kapēc ir ko izvadīt.

Un tad sanāks ka cikā, kas notiek izvadot postus notiek vēl viens cikls.

Respektīvi. Sanāk, ka Widget, kad dodās pēc funkcijas kas izvada pirmo Postu, tad pie pirmā izvades iekšā izvada trīs saites. Izvadot otro pastu atkal vienā ciklā iekšā notiek foreach. Kaut kā nesanāks, kad katru reizi paņems vienu vērtību.

Vajadzētu, kad widget prasa lai izvda pirmo postu, tad paņem pirmo vērtību, kad prasa otru postu, tad otru vērtību un kad trešo, tad trešo vērtbīu.

Varbūt es nepareizā vietā vispār cenšos veikt izmaiņas.

Tas viss tikai mans tāds domu gājiens kā tas varētu notikt.

Ceru, ka iespejams saprast ko es uzrakstīju :)

ieliec arrayā un izmanto foreach

Paldies par ideju!! :)

Tikai buus man japadomaa kaa to uzrakstiit reaali, jo esmu iesaaceejs :)

Blink >>>

Neesmu specs, bet man sciet ka manaa gadijumaa tas nederees, jo nevis tikai vienu vajag izvadiit, bet visus 3 linkus!! :)

Takaa driizaak noderees foreach.

Sveiki!

Kā lai pārveido šo skriptu tā, lai katru reizi nolasītu vienu vērtību:

$raksts1

$raksts2

$raksts3

$raksts1 = 'http://localhost/pakalpojums1/';
$raksts2 = 'http://localhost/pakalpojums2/';   
$raksts3 = 'http://localhost/pakalpojums3/';   


       if($lightbox){
           $images .= '<a title="' . get_the_title($id) .'"  href="'.  $raksts1 /* Max upload size in WP? OR Thumb.php? -> exposure_thumb_url($full_image,920,600) */ .'"><img src="'. $img_url .'" width="'.$w.'" alt="'.get_the_title($id).'" /></a>';   
       } else {
           $images .= '<a href="'. $link .'"><img width="'.$w.'" src="'. $img_url .'" alt="'.get_the_title($id).'" /></a>';
       }

       $images .= '</div>' . "\n";

       if(($iter == $viewable || $loop == $items ) && $slider == true){$images .= '</div>'; $iter = 0;}// Slider wrap
      }

Šajā skriptā tā vērtība ir kā saite uz noteiktu lapu, kutu es norādīšu manuāli skriptā.

Šobrīd ir tā, ka lasa tikai vienu vērtību $raksts1.

Tas ir WordPress widgets, kas izvada attēlus no postiem un defaultā klikojot uz bildi viņš veda uz postu vai palielināja attēlu.

un nepieciešams lai skripts izpildītos tikai 3 reizes katru reizi paņemot nākamo vērtību.

Paldies!

Labāk neatbildēšu. Atkal no'feil'ošu... =D

Varētu jau atbildēt nefeilojot :P

Visu izmainīja pievienojot iekš:

ul#nav {
height: 236px;
width: 800px;
margin: 0 auto;
background-image: url(images/header-bg.jpg);
background-repeat: no-repeat;
       list-style: none

rindiņu:

list-style: none;

ar

"ul#nav li a {
	display: block;
	width: 130px;
	float:left;
	margin-top:150px;

viss bija kedās! :) Sanāk ka tā dekorācija veidoja nevajadzīgu atkāpi vai kaut kā tā.

Bet man patīk tava pieeja ar mājieniem! Veicina domāšanu! :)

Esmu zaļš šajās lietās, bet esmu ķēries klāt apgūšanai :)

Vienīgi kapēc ir tā, ka man <a>, kas ir iniline elements ir jāliek blokā??

Sveiki!

Kāpēc man rādās tādās kā trepēs tā menu, ja viņai vajadētu būt līnijā??

html fails:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>

<body>

<ul id="nav">
	<li><a href="#">Press</a></li>
       <li><a href="#">History</a></li>
       <li><a href="#">Project</a></li>
       <li><a href="#">Press</a></li>
       <li><a href="#">Press</a></li>
     </ul>

</body>
</html>

CSS fails:

@charset "utf-8";
/* CSS Document */

* {
margin: 0;
padding: 0;
}
body {
font-size: 100%;
font-family:Helvetica, sans-serif;
background-color: #f5ecd4;
background-image: url(images/body-bg.png);
background-repeat: repeat-x;
background-position: top;
}
ul#nav {
height: 236px;
width: 800px;
margin: 0 auto;
background-image: url(images/header-bg.jpg);
background-repeat: no-repeat;
}
ul#nav li a {
	display: block;
	width: 130px;
	float: left;
	margin-top: 168px;
}

Kā tas izskatās ir pievienots pielikumā.

Paldies!

Visvienkāršāko vari pats uztaisīt, ja trūkst zināšanu, tad mēģini...

Nu nezinu kāda jēga pašam taisīt forumu no 0, ja ir pilns internets ar kvalitatīviem gataviem produktiem un dažādas sarežģītības.

+labs tutoriālis - zināšanu paplašināšanai.

Sveiki!

Vai ziniet kādas labas lapas ar Drupal tutoriāļiem. Visādiem knifiem, pārskaties, apskatiesutt.

Piemēram: http://net.tutsplus.com .. man ļoti patīk, bet viņi izteikti priež uz WordPress. Par Drupal tik pāris raksti bijuši.

Paldies!

ŠO jau man iekopēja notepad.lv forumā:

http://drupal.org/documentation/customization/tutorials

http://drupal.org/documentation/customization/tutorials/beginners-cookbook

http://dtutorials.com

http://www.siteground.com/tutorials/drupal-tutorial

http://summapro.com/drupal-tutorials

Es par to padziļinātu lasīšanu nejautāju tādēļ, ka man vajag pārtaisīt datubāzi,jo pagaidām pieturēšos pie jau izveidotā modeļa, bet gan tādēļ, ka vienkārši interesē palasīt vairāk!! Vienk sportiska interese!! :)

Ok! :)

Tavs teksts ir pietiekami pārliecinošs, lai es tomēr pacīnītos tagad un izveidotu jau kārtīgu pamatu tam visam! :)

Ir kāda prātīga literatūra latviešu valodā par šo tēmu - grāmatas!!?

Tieši par datu bāžu modelēšanu un dažādām problēmām ar kādām var nākties saskarties utt?? Kur apskatītas situācijas un risinājumi no teorētiskās puses!! :)

Sveiki!! :)

Es turpinu savu mazo piedzīvojumu DB pasaulē! :)

Pagaidām esmu ticis līdz šai vietai!!

Tad nu kad ķēros pie PHP formu ģenerēšanas attapos, ka man vēl tik daudz kas jāpalasa, lai varētu uzģenerēt formu priekš datubāzes kurā ir relācijas! :)

Ja es pagaidām visus datus vāktu vienā tabulā bez relācijām kurai būtu uzģenerētas PHP formas es varēšu pēc kāda laika bez īpašiem sarežģījumiem šos datus sadalīt datubāzē ar relācijām??

Piemēram es pus gadu vākšu tos datus un izmantošu un piemēram pēc pus gada man būs gatava datubāze ar tiem pašiem laukumiem tikai jau smuki strukturizēta.

Neapspriežam to vai man pietiks prāta, bet cik liela ir sarežģītības pakāpe! :)

Paldies!! :)

Nu jā! Tāda man doma arī ir :)

Bet jā... laikam man jāpalasa par šo tematu vairāk ir un tad būs apskaidrība kas un kā :)

+to formu ģeneratoru izmantoju PHPMaker7.

Bet nu jā... jāpalasa kā tur šīs lietas patiesībā būvējās :)

Labi!

Paldies!

Bet patiesībā ir tā... jo vairāk kaut ko saprast sāku, jo vairāk saprotu ka pilnīgi neko nesaprotu :) Palasu kaut ko, lai izprastu un tur jau kaut kas parādās kas atkal jāpēta! :) Un kad kaut ko sāc reāli darīt rodas vesela kaudze jautājumu!! :)

Vakar kad ķēros klāt pie interfeisa ģenerēšanas, tad man radās šāds jautājums.

Piemēram es uzģenerēju formu priekš produktu pievienošanas. Kad pievienoju produktu, tad lai norādītu spiedi man parādās laukums ar spiedes ID, kuru patiesībā lietotājam nemaz nevajag redzēt. Tam jāpaliek nepamanām. Un arī tas spiedes ID viņam reāli neko nedos. Viņs var vadīties tikai pēc spiedes numura. Tad kā tur reāli jāveido formās?

Vienā skatā jābūt ir laukumiem no produkta un no spiedes?

Nevarētu palīdzēt kāds ar šo jautājumu?? :)

Labs vakars :)

Diez šodien visi pa krogiem vai pie datoriem arī kāds sēž :)

Iepriekš es jau biju izvērsis diskusiju par datu bāzes modeli, tad nu tagad man aktuāls jautājums ir par ārējo atslēgu definēšanu.

Ideju kā darbojās ārējās atslēgas es saprotu, bet es nemāku iekš MySQL Workbench nodefinēt viņas!

Visu savu stāstu es balstu uz pielikumā pievienoto attēlu!

Pēc iepriekšējās diskusijas un ieteikumiem es izlēmu ka ārējās atslēgas būs tikai tabulai moltz_products.

Tad nu es vēlos tabulai "moltz_products" piesaistīt tabulu "moltz_press".

Mani nepamet sajūta, ka es esmu nepareizi nodefinējis tās atslēgas!

Rēlācijas starp tabulām:

1. Produktam var būt piesaistīta tikai viena prese

2.Presei var būt piesaistīti n-tie produkti

3.Produktam var būt piesaistīts tikai viens klients

4.Klientam var būt piesaistīti n-tie produkti

Ja nav pareizi, tad kā pareizi man nodefinēt!

Paldies :)

Ok!

Tā es arī darīšu!! Izmantošu automātisko ģenerēšanu.

Bet vai šis pielikumā esošais DB modelis būs ok. Un laukumi ārējām atslēgām?? :)

Tad iespējams par to vietu der padomāt, vai tas nav kā klasifikators (ierobežota vērtību kopa), lai viens neraksta augšējais plaukts, otrs trešais plaukts no apakšas un trešais pirmais no augšas.

Jā! Par to novietošanu plauktos ir tā. Sadalīti ir A, B, C, D ...

Un tad spiedei tiek piešķirta vieta:

A1, C12, E23... un Burts norāda plauktu, bet skaitlis kura spiede pēc kārtas. Un uz sāniem arī viņai parasti ir uzrakstīts piem A5. Tad pieejot pie plaukta uzreiz redzu kura ir A5.

Tad vēl sīkums, protams, bet nestilīgi, ka tiek jauktas valodas. Vai nu visu latviski, vai angliski

Tas jā :) Viss būs vienā valodā! Es vienk tagad tā pielabojot, ierakstu tad tā, tad tā :)

+ kaut kas minēja, ka klienta nosaukumu izmantot kā ID. Neesmu eksperts, bet vai tas nevarētu radīt problēmas, ja pie klienta ievadīšanas tiks norādīts nepareizs nosaukums, tad pēc tam būs grūti atrast viņu?

Un tas pats par pašu spiedi. No vienas puses viņas numurs, kas tiek iededzināts uz viņas ir unikāls!! Bet viņu tomēr ievada ar roku!! Ja nu piemēram pārskatās un 6 vietā ievada 8. Tad pēc reālā cipara viņu neatradīs! Tādēļ man šķiet ka ID šajā DB labāk ir ģenerēt automātiski.

manā varaintā 2 tabulas ir neatkarīgas, trešā saistīta ar abām. Kopā 3.

 

 

Tavā pēdējā grafika gadījumā, ja tu norādi klientam product_id, tas nozīmē, ka klientam varēs būt tikai viens produkts, tāpēc labāk ir produktam norādīt clienta id, tāda'veidā piesaistot produktu pie klienta.

 

Savukārt, ja spiedei norādi product_id, tad katrai spiedei varēs būt viens produkts, bet tu raksti, ka vajag:

 

Tāpēc vajag produktam norādīt press_id, tādā veidā viens produkts ir piesaistīts konkrētais spiedei un spiedei var būt piesaistīti daudzi produkti.

Cool :) Ineresanti, kad palasa kaut ko un reāli ķeras pie prakses .. :) tad viss izskatās pavisam savādāk :)

Sapratu reālo problēmu ar manu pirmo variantu.

Vai tu atbalsti šādu modeli, kādu pievienoju tagad pielikumā?

+ ieboldēju tos laukumus kuri ir nepieciešami.

Es vispār nesaprotu par kādu secību jūs tur ar Grey_Wolf runājat, jo sql datubāžu tabulām nav nekādas tabulu secības.

Es piedāvāju izveidot 2 neatkarīgas tabulas: clients un presses, un tabulu products, kura norāda gan uz clients, gan uz presses.

 

Tas ir vienalga, vai tu pirmo pievieno tabulā spiedi vai klientu, un tad, kad abi ir pievienoti, tad var pievienot produktu, kurš norāda uz attiecīgo klientu un attiecīgo spiedi.

Bet pat šijā gadījumā nav strikta secība, jo tu vari pievienot klientu un tad pievienot produktu, norādot press_id=0, kas nozīmēs, ka prese vēl produktam nav piesaistīta un to būs jāizdara vēlāk.

OK!

Kādēļ divas tabulas nevis 3?? Jo katra no trim klāsēm jau man saturēs objektus. Cik nu es esmu palasījies, tad es saprotu, ka vajag trīs tabulas manā situācijā.

Un attiecībā uz sasaiti. Klients var būt datubāzē bez produkta un produkts var būt bez spiedes, bet spiede bez produkta nevar būt. Ja spiede ir viena pati, tad mēs viņu metam ārā. Lai neizveidojas arī situācija, kad piemēram spiede "karājās" db viena pati un atrodi nu kuram produktam viņa ir piesaistīta.

Pagaidām bez sazīmētām relācijām pielaboju tās tabulas.

Vai šāda tabulas ar šādiem laukiem būtu ok?

...

pievienoju attēlu pa jaunam, jo biju aizmirsis vienu laiku!! :)

clients

-------

id

citi_dati

 

 

products

--------

id

client_id

press_id

citi_dati

 

presses

--------

id

citi_dati

 

 

kaut kā šādi.

Ja vajag dabūt klienta produktus, tad

SELECT * FROM products WHERE client_id=123;

 

Ja vajag dabūt kāda produkta presi, tad

SELECT * FROM products p,presses p2 WHERE p.press_id=p2.id and p.id=345;

No tavas secības es sapratu, ka tu atbalsti to ka tabulas sasaistītas:

Klients-->Produkts-->Spiede

Vai tu vienkārši tā uzrakstīji jo es biju tādu secību izvēlējies?? :)

Es vienkārši gribu saprasti kādu secību man vajag!!

Grey_Wolf

Vari lūdzu nedaudz sīkāk aprakstīt kā nākotnē varētu tas ietekmēt, ja es izvēlos kā pirmo spiedi un kā, ja es izvēlos kā pirmo klientu!! :)

Es reiz sāku rakstīt par datu modelēšanu, tiesa gan pārāk tālu netiku. Bet gan rakstā, gan komentāros ir papildus saites, tai skaitā uz saitu, kurā ir kāds bariņš ar modeļiem. neteikšu, ka man tie visi patīk, bet kaut kādas idejas iespējams var paņemt

Labi!! Šo es papētīšu!! :)

Nu laukus aka atribūtus jau nu gan neviens Tavā vietā neizdomās. Nu piemēram klientam varētu interesēt banka, bankas konta nr, uzņēmuma reģistra numurs, juridiskā adrese, lai varētu izdrukāt automātisku rēķinu vai vismaz tā veidlapu. Visas tādas lietas ir ļoti atkarīgas no tā, ko Jūs darat un ko Jums vajag.

Pagaidām mēs tiešām gribam tikai vākt pamat datus. Jo kādēļ to DB veidoju..., lai būtu vieglāk atrast pašas spiedes, bet tad ienāca prātā doma, ka kaut kādu pamatinformāciju par klientu varētu vākt un arī pamatinformāciju par produktu, lai menedžerim izveidojot pasūtījumu (ko viņš dara aizpildot word dokumentā formu) būtu iespējams pārbaudīt vai spiede ir kārtībā vai nevajag pasūtīt jaunu, paskatīties kāds dizains ir produktam utt. Nu tāda pamatinformācija par šīm trim lietām... Klients, produkts, spiede!

Un tieši tādēļ es izvēršu šo diskusiju šeit, lai uz priekšdienām, kad kāds izdomās izveidot mega bāzi, tad šīs tabulas un dati būtu noderīgi. Lai šim DB modelim varētu pievienot jaunas tabulas un veiksmīgi ar viņām darboties! :)

>Kā pareizi sasaistīt tabulas utt!

Šim mērķim izmanto ārējās atslēgas (foreign key) kolonas, kurās liek saistītās tabulas primāro vai unikālo atslēgu, ko Tu jau esi savās tabulās iezīmējis, kā id kolonas. Tātad, ja vienam klientam var būt 0 līdz N produkti, bet katram produktam ir tieši viens klients, kas to ir pasūtījis, tad acīmredzot produktu tabulā ir kolona klienta id, kas norāda, kurš klients šo produktu ir pasūtījis.

OK. Es mēģināšu pārveidot ar tām foreign key nedaudz pielabot situāciju, bet man nav īsti skaidrs kā noteikt kas ir pirmā tabula ar kuru sākt un kurai piesaistīts pārējās tabulas, lai nākotnē arī jaunas opcijas varētu veiksmīgi piekabināt.

Kā jau minēju, tad šobrīd ir tā ka process norit šādi:

Klients-->Produkts-->Spiede

Bet kā man norādīja Grey_Wolf:

paraizek buutu sakt ar UNIKALO vertiibu kas buutu spiede

taatad..

1. Spiede

2. Klients

3.Pasuutijums

Varbūt tomēr varētu šeit nedaudz apstāstīt kādēļ tā, jo citiem jaunajiem arī būtu noderīga informācija :)

Skatoties uz Tavu apgalvojumu, ka vienam produktam var būt tikai viena spiede, man gan tas liekas mazliet šaubīgs - a kas notiek tad, ja spiede saiet dēlī un jāiegādājas jauna? Vai tā nemaz nevar būt? Iespējams, ka mans jautājums ir muļķīgs bet domājot par attiecībām starp objektiem šīs lietas vienmēr jāņem vērTiesa gan, protams, pārāk tālu detaļās arī nevajag ieslīgt, ir jau sākumā jānosprauž robežas, kas būs, kas nebūs, lai varētu saprātīgā laikā nonākt pie kaut kā derīga.

--> "vienam produktam var būt tikai viena spiede"

Jā! Vienam produktam var būt viena un tikai viena spiede! :) Ja spiede saiet dēlī, tad:

->Ja iespējams, salabojam paši nomainot bojāto nazi

->Ja nav iespējams salabot, tad sūtam jaunu un veco matam ārā. Jaunajai spiedei ir pilnīgi tāds pats numurs kā vecajai. Man vienā reizē bija tā, ka es vienu dienu nočakarējos uzstādot vienu spiedi un izrādijās, ka blakus stāvēja pilnīgi jauna un to uzstādīt aizņēma 1h. Takā, ka ir divas spiedes, tad jau lažu ir nolaidis "Die cutters" kurš nav izmetis veco.

Pie tam vai nav tā, ka cits klients var pasūtīt precīzi tādu pašu produktu, kā iepriekšējais un jūs varat izmantot veco spiedi?

Precīzi tādu pašu nepasūtīs, jo mēs ražojam iepakojumus un dizainiski nebūs tāds pats produkts, BET var būt tāda paša izmēra un tipa produkts. Tad protams mēs izmantojam vienu spiedi vairākiem produktiem, bet ne veco, jo vecā ir nelietojusies ... naži neasi vai sabojāti utt. Viņa vairs negriež papīru.

Kas notiek tad, ja kāds klients pēc laika grib atkal to pašu, ko jau reiz pasūtīja, vai tas ir jauns produkts?

Tad tas nav jauns produkts. Tas jau ir esošs produkts. Menedžeris nočeko datubāzē vai ar spiedi viss ir ok. Datubāzē var paskatīties dizaina failus un skices un ja ir kaut kādi jautājumi klientam, tad datubāzē glabājās pamatinformācija par klientu, lai operatīvi viņu sazvanītu.

ā. Vai jūs interesē produkta pasūtījumi un to izpilde?

Protams, bet ne tagad! Un tieši tādēļ es gribu, lai pati datubāze ir ok izveidota, lai pēc kāda laika X, tad būs iespējas veidot kaut ko nopietnāku, tad var izmantot jau esošās pamatus utt.Paredzot, ka nākotnē varēs glabāt klienta bankas info, pasūtījumus utt. Lai viss ir vienkopus. Arī informāciju par to cik daudz papīra ir noliktavā. Lai veidojot pasūtījumu norāda cik daudz papīra aizies un jau saprast vai vajag pasūtīt vēl utt. Bet tas nākotnei! :) Pagaidām vienk., lai operatīvi varētu atrast kur atrodas spiede. Jo piemēram ja reizēm lai atrastu vienu spiedi tas aizņem 10 min tad ja dienā ir piem jāsagriež vismaz 6 produkti, tad 1h vienk dienā pakāsta meklējot starp 15 A4 lapām kurās ir kādas 6 tabulas. Izej cauri 1x un neatrodi un tad lēnāk atkal meklē utt :) vienk laika zaudēšana. Tādēļ es vēlos ar jūsu palīdzību izveidot labu pamatiņu un ar kādu PHP ģeneratoru formas izveidot un sākt jau vadīt datus :)

Ceru uz suportu :)

Daudz vēl jālasa man, lai kaut nedaudz būtu skaidrība par to visu :D

Neliels ieskats par kādām spiedēm runāju :) Šajā aparātā viņas liek.

Un pielikumā ir fails kur redzama ir pati spiede. Ar sarkano kvadrātu esmu apvilcis to vietu kur var redzēt spiedes numuru, kas ir unikāls.

OK! :)

Paldies, par norādēm! ;)

Rītdien labprāt pakonsultēšos par šo jautājumu un padiskutēšu, lai izveidotu labu pamatu datubāzei.

Kādu dienu pēc gada vai vairāk, ja kāds izdomās veidot nopietnu DB, lai vismaz dati ir saknē jau kvalitatīvi un šobrīd mēs varētu operatīvi atrast spiedes plaiktos un kuram produktam utt.