[Apache, phpmyadmin, html, PHP, ...] Datenbank mit webbasiertem Zugriff erstellen

[boss3D]

@ TessaKavanagh
Excel-File kommt noch heute. Ich richte es gerade her. Kommt dann hier im Anhang rein.

[EDIT]
Anhang anzeigen vorlage.7z
^^ Die einzelnen Zellen in den Spalten Tätigkeiten und Produkte waren ursprünglich Dropdowns, falls das was zur Sache tut

@ DarkMo
Jetzt haben wir soviele Ansätze diskutiert, dass ich schon gar nicht mehr weiß, welchen ich denn jetzt beginnen oder weiterverfolgen soll. Ich schau mir morgen mal deine Idee mit der Tabelle an. Klingt ja eigentlich ganz gut, zumindest solange ich es effizienter und dynamischer umsetzen kann als meinen ersten Versuch.

@ Rho
Die Entscheidung ist nun mal auf eine html/php Lösung gefallen. Das wird sich nicht mehr ändern, und deine ständigen pseudo-sarkastischen Kommentare dazu sind leider wenig hilfreich.

 

[Rho]

Und das klappt bisher ja auch ganz ausgezeichnet.

Mal davon abgesehen, war mein Kommentar bezüglich Buch, um eine Sprache von Grund auf zu lernen völlig ernst gemeint.
Das Datenbankschema, zu dem ich einen Kommentar abgegeben habe, ist übrigens wirklich völlig Banane. Ganz ohne "Pseudosarkasmus".

 

[boss3D]

Ich hatte aus deinem letzten Posting eh nur die eine Meldung bzgl. html/php Lsg. gemeint. Jedenfalls lernen hier alle aktiv mitarbeitenden was und gerade das macht die Sache m. E. so interessant. Also mir macht's Spaß, php zu lernen und ich habe bei dem Projekt zum Glück keinen Zeitdruck.

Wenn man sich in was Neues einarbeiten muss, wird selten der erste Versuch gleich ein Meisterwerk. Deswegen versuchen wir ja auch immer noch, den bestmöglichen Lösungsansatz zu finden. Was trägst du dazu bei, außer immer wieder negative und somit sinnlose Kommentare einzustreuen?
Wenn du dich nicht konstruktiv beteiligen willst, warum sparst du dir dann nicht die Zeit, überhaupt hier zu posten?

PS: Excel ist jetzt im vorigen Posting angehängt.

 

[Rho]

Auf Fehler und Probleme hinzuweisen finde ich durchaus konstruktiv.
Meine Hauptmotivation ist allerdings, dass ich den Thread einfach unterhaltsam finde.

Hättest du dich für irgendwas anderes als PHP entschieden, hätte ich dich sicher auch mehr unterstützt. PHP tue ich mir allerdings in meiner Freizeit nicht freiwillig an.

Du solltest dir jedenfalls erstmal ein halbwegs vernünftiges Datenbankschema überlegen.

 

[DarkMo]

also ich mag php seeeehr ^^ weis garnich, wie man das nich leiden kann

 

[Rho]

Wie auch immer. Auf das Endergebnis bin ich schon sehr gespannt.

 

[boss3D]

Auf Fehler und Probleme hinzuweisen finde ich durchaus konstruktiv.

Konstruktiv ist für mich, seiner Kritik auch Verbesserungsvorschläge folgen zu lassen ...

also ich mag php seeeehr ^^ weis garnich, wie man das nich leiden kann

Dem schließe ich mich mittlerweile an. Ist zwar immer noch mühevoll, aber es macht Spaß, sich da einzuarbeiten.

Du solltest dir jedenfalls erstmal ein halbwegs vernünftiges Datenbankschema überlegen.

In meinem Kopf habe ich schon eine ziemlich genaue Idee, was ich haben will. Ich weiß allerdings noch nicht, ob das in der Form realisierbar ist, oder ob ich wieder eine andere Lösung brauche.

Jedenfalls hätte ich mir gedacht, ich brauche erstmal mehrere "kleine" DBs.
- Eine heißt derzeit "homepage" (ja, nicht ganz aussagekräftig, der Name) und nimmt alle User, die sich, bevor sie sich einloggen können, registrieren müssen, auf. --> id, passwort, username
- Eine andere heißt "produkte" und enthält eben alle 20 Produkte. --> id, produktname
- Eine weitere heißt "taetigkeiten" und enthält die 11 Tätigkeiten. --> id, taetigkeit

Und am Ende sollen (so vermute ich) ALLE Daten in EINER DB landen, die dann in ein vernünftig strukturiertes Excel-Dokument exportiert werden kann.
- Deswegen vielleicht eine DB "projektzeiterfassung" anlegen?! --> ??? (Spalten)

^^ Im Grund stelle ich mir das ungefähr so vor, dass die "kleinen" DBs die jeweiligen Daten aus dem online-Formular aufnehmen. Und dann, sofern möglich, liefern die "kleinen" DBs diese an die eine große "Über-DB" weiter.
Oder, um uns vielleicht Arbeit zu ersparen, könnte man vielleicht auch einfach gleich nur die eine große DB, die bereits Spalten für Produkte, Tätigkeiten, Zeit, etc. enthält, erstellen und dann eben die Daten aus den einzelnen Formularfeldern (dropdowns, checkboxen, whatever, ...) immer nur an die jeweilige Spalte in der großen DB übertragen.
So eine "große DB" müsste es dann eben für jeden einzelnen User geben. Vielleicht sogar noch dynamisch erstellt, sobald sich dieser registriert.

K. A. was davon oder inwieweit sich das so umsetzen lässt, aber soweit jedenfalls meine Vorstellung von dem ganzen ...

Was die Umsetzung betrifft: Daten in php aus DBs holen, ist mir schon einigermaßen klar. Zuerst Verbindungsaufbau mit mysql_connect(), dann eben die Spalte ($row) auswählen, und mit der id auf die Daten zugreifen. Wie das jetzt umgekehrt geht, mit Daten an eine DB senden, weiß ich noch nicht so genau, aber vermutlich recht ähnlich. In meinem registrier-php-Script (heißt eigentlich eintragen.php) passiert ja schon genau das. Nur stammt der Code halt wieder aus dem Web und ich habe ihn nur entsprechend angepasst, damit er für das Projekt passt. Aber das finde ich da schon an, wie das zu machen ist.
--------------

Ich möchte zumindest die "Useroberfläche" jetzt erstmal nach der Idee gestalten:

wieso setzt du das ganze nicht vergleichbar der exel tabelle um?

ich stell es mir gerade so vor:
du baust die tabelle wie die exel dinges das vorgibt nach.
du hast einen statischen teil: den header. also die überschriften szs
du hast einen dynamischen teil: den inhalt schon gespeicherter datensätze
un du hast nochmal einen statischen teil: die eingabe maske für neue datensätze
naja und untendrunter noch die summen zusammenfassung

Wie das dann "im Hintergrund" ausschauen muss, da hätte ich bitte gerne ein paar Kommentare zu meiner Idee (siehe über Trennlinie in diesem Posting).

@ DarkMo
Hattest du beim dynamischen Teil gemeint, dass da html-dropdowns angelegt werden, die für ihre Auswahlmöglichkeiten auf die produkte- bzw. taetigkeiten-DB zurückgreifen (also deren Inhalt anzeigen)? Oder eben checkboxen, die in der Anzahl der Inhalte der jeweiligen DB dynamisch angelegt werden?

BTW: Läuft das nicht am Ende wieder auf Tessa's Idee raus, dass ich mehrere Seiten brauche? Ich lasse mir bspw. erstmal dynamisch die checkboxen für Tätigkeiten erstellen. Dann wählt der MA bspw. 3 aus, und jetzt brauche ich eine Möglichkeit, ihm die Produkt-Auswahlmöglichkeiten so anzuzeigen, dass er genau angeben kann, in welcher Tätigkeit er an welchem Produkt beschäftigt war. Ergo Seite 2? usw. ?

 

[Rho]

Konstruktiv ist für mich, seiner Kritik auch Verbesserungsvorschläge folgen zu lassen ...

Da du bisher für Vorschläge meinerseits absolut nicht empfänglich warst, sah ich darin keinen tieferen Sinn.

Dem schließe ich mich mittlerweile an. Ist zwar immer noch mühevoll, aber es macht Spaß

Mag überraschend kommen, aber es gibt Sprachen die sind nicht mühevoll und machen trotzdem Spaß.

Jedenfalls hätte ich mir gedacht, ich brauche erstmal mehrere "kleine" DBs.
- Eine heißt derzeit "homepage" (ja, nicht ganz aussagekräftig, der Name) und nimmt alle User, die sich, bevor sie sich einloggen können, registrieren müssen, auf. --> id, passwort, username
- Eine andere heißt "produkte" und enthält eben alle 20 Produkte. --> id, produktname
- Eine weitere heißt "taetigkeiten" und enthält die 11 Tätigkeiten. --> id, taetigkeit

*seufz*

Mit "kleine DBs" meinst du hoffentlich Tabellen. Falls du wirklich planst für jeden Mist eine eigene Datenbank anzulegen, solltest du dein Vorhaben nochmal überdenken.
Du hast dann also eine Tabelle mit Namen Homepage, in der die Daten der Benutzer gespeichert werden. Ganz verrückte Idee, warum nennst du die Tabelle nicht einfach User?
Die Tabellen Produkt und Taetigkeit sind ja so weit in Ordnung. Du solltest dir aber noch überlegen, wie du die Beziehung zwischen Produkten und Tätigkeiten in deinem DB-Schema abbilden willst. So weit ich das mitgekriegt habe, kann man für ein bestimmtes Produkt ja auch nur ganz bestimmte Tätigkeiten auswählen. Dafür brauchst du also noch eine weitere Tabelle.

Und am Ende sollen (so vermute ich) ALLE Daten in EINER DB landen, die dann in ein vernünftig strukturiertes Excel-Dokument exportiert werden kann.
- Deswegen vielleicht eine DB "projektzeiterfassung" anlegen?! --> ??? (Spalten)

Ja, richtig erkannt. Du brauchst dann natürlich auch noch eine oder mehrere Tabellen um die Eingaben der Benutzer in der DB zu speichern.

^^ Im Grund stelle ich mir das ungefähr so vor, dass die "kleinen" DBs die jeweiligen Daten aus dem online-Formular aufnehmen. Und dann, sofern möglich, liefern die "kleinen" DBs diese an die eine große "Über-DB" weiter.
Oder, um uns vielleicht Arbeit zu ersparen, könnte man vielleicht auch einfach gleich nur die eine große DB, die bereits Spalten für Produkte, Tätigkeiten, Zeit, etc. enthält, erstellen und dann eben die Daten aus den einzelnen Formularfeldern (dropdowns, checkboxen, whatever, ...) immer nur an die jeweilige Spalte in der großen DB übertragen.

Eventuell hilft es dir, das ganze mal in einem kleinen Diagramm darzustellen, in dem dein gesamtes Datenbankschema sichtbar ist.

So eine "große DB" müsste es dann eben für jeden einzelnen User geben. Vielleicht sogar noch dynamisch erstellt, sobald sich dieser registriert.

Das ist ja mal völliger Quark. Es reicht doch einfach zu jeder Zeiterfassung die User-Id zu speichern um die Verbindung zwischen User und Datum herzustellen.

 

[DarkMo]

also mir scheint gerade auch, dass du eine völlig falsche vorstellung von datenbanken hast. da kann man rho nur unumstritten recht geben: für jedes pisselding ne eigene db? das is nich nur unnötig, das geht doch völlig am prinzip vorbei ^^ ich teile die hoffnung, dass du nicht db's meinst, sondern tabellen. du kannst in einer db doch zig tabellen erstellen. du kannst zwar mehrere db's per php ansteuern, aber wie gesagt - wozu? das lässt sich locker in einer db realisieren. nen grobes konzept (soweit ich das bisher blicke) könnte so aussehen:

EINE db mit namen zeiterfassung (zum bsp)
darin die folgenden tabellen mit stichpunktartig genannten spalten:

taetigkeiten
- id
- name

produkte
- id
- name (oder bezeichnung oder oder)

prod_taet
- id
- teatigkeit (per id)
- produkt (per id)

user
- id
- name
- pw (md5)
(- eventuell sowas wie status (admin, abteilungschef... ginge schon in richtung rechtesystem))

zeiten
- id
- teatigkeit (per id)
- produkt (per id)
- user (per id)
- bemerkung
- zeit
- datum
- erstellt


sinn des ganzen:
produkte und taetigkeiten sollte klar sein. erstmal grundsätzlich speichern, was es so gibt. das kann man dann für die dropdowns (selectboxen - hab bei meinem tabellen bsp glaube ausversehen normale inputs genommen) auslesen und diese damit befüllen. ändert wer was in der db, wird das automatisch und eben dynamisch übernommen. bsp code gabs ja auch schon. würde man dann halt die einzelnen <option> tags dynamisch generieren lassen.

prod_taet soll eine verknüpfung sein. da steht drin, welche produkte zu welche tätigkeiten gehören. wir haben meinetwegen eine tätigkeit klogang (taet id 1) mit dem produkt wurst (prod id 1), und ein weiteres dabei nutzbares produkt wäre.. naja, ne ^^ (prod id 2) dann würde in der tabelle eben stehen:
1 1 1 (tabellen id, teatigkeit mit id1 -> klogang, produkt mit id1 -> wurst)
2 1 2 (tabellen id, wieder teatigkeit mit id1 -> klogang, produkt mit id2 -> nuja)

hat man eine 2. tätigkeit und kann hier auch ne wurst als produkt nutzen, wäre das auch kein thema:
3 2 1

gut, man möge das blöde bsp verzeichen, aber mir wollte ums verr... nix besseres einfallen grad

so, user betrifft dann schon ein loginsystem. ohne das, braucht man auch die tabelle nich. speichert halt den (login)namen und sein pw. kann man auch das registrierungsdatum und ggf persönliche einstellungen din speichern (also nich unbedingt relevant denk ich mal), aber so sollte es fürs gröbste völlig ausreichend sein.

jow, und zeiten erfasst halt die einzelnen einträge. also das ist quasi der kern der db. alles andere drum herum sind grundinfos szs. hier wird jetzt das gespeichert, was quasi auch in der excel tabelle steht. ein kleines organisatorisches prob ergibt sich aber (was ich beim tabellen bsp schon vermutet hatte): bei deinem bsp bild hast du in einer zeile teils 3 zeiteintragungen - das ginge mit diesem system nicht. eine zeile, eine zeit für ein datum. man könnte das jetzt nochmal aufbrechen, dass man die tätigkeit mit dem produkt und der bemerkung unter einer id speichert in der tabelle eintrag meinetwegen und das aus der tabelle zeiten rausnimmt. und in zeiten kommt dann wieder ein verweis zu eben jenem eintrag (per id) rein. dann kann man für einen eintrag auch mehrere zeiten für verschiedene daten speichern. müsste man dann aber irgendwie aufpassen, dass man ned für ein datum mehrere zeiten angeben kann oder so. aber das sind glaube feinheiten für später.


und wegen den dropdowns und javascript: du kannst es mMn auf 2 varianten lösen: entweder nimst du immer eine volle produkte-liste her und löscht selektiv alles, was nich zur tätigkeit passt, oder du baust für jede tätigkeit ein eigenes dropdown menü, was du dann in ein div packst mit der id der tätigkeit, welches erstmal unsichtbar ist. wird eine tätikeit gewählt, änderst du einfach nur das entsprechende div (anhand der id) soweit ab, dass es sichtbar wird (und alle anderen unsichtbar). dat funzt jedenfalls ganz gut so ^^

 

[TessaKavanagh]

So mein Wochenende ist momentan etwas stressig, sodass ich noch nicht zum Basteln gekommen bin. Aber DarkMo hat dir ja einen vernünftigen Ansatz bezüglich Datenbanken geliefert. Hier muss aber m.E. noch ergänzt werden das eine Verschlüsselung der Passwörter mit md5 nicht ratsam ist. Ich würde hier ehr zu sha512 raten. Außerdem solltest du das Passwort mit einem hardgecodeten Salt verstärken. Zusätzlich benutzt du dann noch eine zufällig generierte Zeichenfolge(für jeden user) die du ebenfalls im Klartext in die DB speicherst (Das dient dazu das wenn zwei Nutzer das gleiche Passwort benutzen trotzdem ein einzigartiger Hash generiert wird.), so werden Angriffe mit Rainbow Tables nahzu unmöglich.

 

[boss3D]

OKay, vielen Dank! Dass ich in einer DB beliebig viele Tabellen haben kann, habe ich einfach nicht gewusst. Wenn's geht, dann kann ich natürlich den Ansatz von DarkMo verfolgen.

@ Tessa
Klingt schlau, aber ich hebe mir das erstmal für später auf. Als erstes soll überhaupt erstmal das ganze Ding stehen und funktionieren, dann kümmere ich mich um die Feinheiten.
-------------

So hätte ich jedenfalls jetzt begonnen, das Formular möglichst ähnlich der Excel-Tabellen aufzubauen (die ganzen "a"s sind nur da, weil sonst die Zeile nicht vernünftig angezeigt würden), aber ich sehe immer noch nicht, wie ich da jetzt drum herum kommen soll, nicht für jedes Feld ein eigenes dropdown oder eine eigene textbox erstellen zu müssen. Was dazu führen würde, dass ich dann am Ende vielleicht ~50 solche html Elemente habe, die ich alle mühevoll einzeln per php ansprechen und auswerten müsste.



Die schönste Version wäre es m. E., nur eine einzige Zeile zu erzeugen und darunter einen "+" Button oder irgendsowas einzufügen. Wenn der MA auf diesen klickt, kommt einer weitere Zeile hinzu. Aber da weiß ich wieder nicht, ob sich das so dynamisch realisieren lässt ...

 

[DarkMo]

na du baust doch schon wieder ne statische tabelle. das was ich dir gezeigt hatte (mit dem dynamischen teil bla) war doch genau das, was du im letzten satz meinst wenn du die ganze sache frisch startest, dann hast du den tabellen kopf mit den spalten überschriften und gleich darunter die add-zeile - mehr nicht. addest du diese zeile, hast du eben wieder den tabellenkopf, gefolgt von deinem eintrag und dann erst die add-zeile.

du kannst die tabelle natürlich auch in der form hier präsentieren und füllst eben von oben her nur die mit zeugs, wo es was zu füllen gibt. also das die tabelle immer 20 zeilen (oder so hat), aber eben erstmal leer ist. die erste zeile wird gleich von der add-zeile belegt. addest du etwas, rückt die add zeile szs eins runter (danach wieder 18 leere zeilen) und davor ist die geaddete zeile.

 

[boss3D]

Das Bild war eh nur "symbolisch" gedacht. So wollte ich's eh nicht lassen ...

Ich habe jetzt die EINE DB "projektzeiterfassung" mit allen von dir vorgeschlagenen Tabellen angelegt, allerdings kämpfe ich gerade damit, meinen Registriervorgang (eintragen.php) so abzuändern, dass die Daten (username, passwort), die ein MA eingibt, jetzt nicht mehr in DB "homepage" (Tabelle: users) landen, sondern in "projektzeiterfassung" (Tabelle: user).

Eigentlich würde ich meinen, alles bedacht zu haben, aber ich kriege folgenden Error:

Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in C:\xampp\htdocs\db\eintragen.php on line 17
Fehler beim Speichern des Benutzernamens.

<?php
$verbindung = mysql_connect("localhost", "root" , "root") or die ("Verbindung zur Datenbank konnte nicht hergestellt werden");

mysql_select_db([COLOR=blue][B]"projektzeiterfassung"[/B]) or die ("Datenbank konnte nicht ausgewählt werden.");

$username = $_POST["username"];
$passwort = $_POST["passwort"];
$passwort2 = $_POST["passwort2"];

if ($passwort != $passwort2 OR $username == "" OR $passwort == "") {
    echo "Eingabefehler. Bitte alle Felder korrekt ausfüllen. <a href=\"eintragen.html\">Zurück</a>";
    exit;
}
$passwort = md5($passwort);

$result = mysql_query("SELECT id FROM [COLOR=blue][B]user[/B] WHERE username LIKE '$username'");
$menge = mysql_num_rows($result);

if ($menge == 0) {
    $eintrag = "INSERT INTO [COLOR=blue][B]user[/B] (username, passwort) VALUES ('$username', '$passwort')";
    $eintragen = mysql_query($eintrag);

    if ($eintragen == true) {
        echo "Benutzername <b>$username</b> wurde erstellt. <a href=\"login.html\">Login</a>";
    } else {
        echo "Fehler beim Speichern des Benutzernamens. <a href=\"eintragen.html\">Zurück</a>";
    }
} else {
    echo "Benutzername schon vorhanden. <a href=\"eintragen.html\">Zurück</a>";
}
?>

Bin gerade noch am googeln, wodurch das passieren könnte ...

[EDIT]
Hab's schon. Dafür bin ich jetzt bei ...

Notice: Trying to get property of non-object in C:\xampp\htdocs\db\login.php on line 16
Benutzername und/oder Passwort waren falsch.

... im nächsten Schritt.

[EDIT2]
So, auch erledigt. Dann schaue ich mir das jetzt mal mit der dynamischen Zeilenerstellung an ...



Irgendwie so: Der Button soll ein php Script aufrufen, das nichts anderes macht, als eine Tabellen-Zeile gemäß dem Excel-Schema zu bauen.

 

[DarkMo]

wozu willst du denn irgendwelche externen scripte aufrufen? die hauptnutzung für sowas liegt eigentlich bei der ausgliederung von größerem code. zur separierung oder so. also bspw konstantendefinitionen/globals, oder meinetwegen funktionen, die nicht im hauptfile mit drin stehen sollen, damit die nicht alles zumüllen, oder eben auch klassen, die man als eigene php erstellt, um die übersichtlichkeit zu gewährleisten. doch aber nich um nen 2zeiler auszulagern.

hab dir btw mal ganz fix meine idee hardcoded erstellt (also plain html):


du hast einfach deinen tabellen kopf (erste zeile) ganz oben, dann eben die einträge aufgelistet, die schon in der db stehen (hier 2 lustige zeilen) und darunter eine weitere zeile, in der man einfach einen neuen datensatz anfügen kann - fertig. dahinter die entsprechenden buttons. das lässt sich alles in nen paar zeilen code bewerkstelligen, da muss man nix auslagern ^^ bin jetz aber auch gleich erstmal für nen tag nich da, daher nur sone larifari beispiel lösung.

 

[XPrototypeX]

@boss3D

soll ich dir mal eine mögliche Lösung in Java + GWT coden um dir zu zeigen wie eine wahrscheinlich bessere und schnellere Lösung aussehen könnte?

 

[boss3D]

@ DarkMo
Nur am Rande erwähnt: Die derzeit vorhanden Daten (also Excel-Dokumente) müssen nicht auch noch in die DB wandern. Die Lösung hier wird für zukünftige Daten (die aber nach dem selben Schema aufgebaut sein werden) entwickelt. Zeile 1 und 2 unterhalb des Headers in deinem Beispiel bräuchte es daher nicht. Zeile 3 sollte eigentlich gleich nach dem Header kommen, bzw. dann, wenn man auf meinen "neue Zeile einfügen" Button klickt.

Wie allerdings alleine die 3. Zeile ein "Zweizeiler" im Code werden soll, sehe ich nicht. ATM stelle ich mir das eher in Richtung 50 Zeilen vor, aber mal schauen.

@ XPrototypeX
Anschauen tue ich es mir gerne, wenn du es machen willst. Würde mich auch tatsächlich interessieren, aber ich glaube trotzdem nicht, dass mich was anderes vom aktuellen Ansatz abbringen wird.

 

[TessaKavanagh]

Vielleicht noch als Anmerkung. Die Befehle mysql_* sind in der Aktuellen PHP Version deprecated, die werden also zukünftig komplett entfernt. Wenn du dich also wirklich einarbeiten willst, solltest du zumindest nach dem Erstellen der Scripte alles auf mysqli_* oder PDO ändern. Der Vorteil an einem PDO Aufruf ist das du Ihn Datenbankübergreifend verwenden kannst. Die Syntax unterstützt nicht nur mysql -

 

[boss3D]

^^ Hab's gerade testweise überall geändert, aber nur damit ist es definitiv nicht getan. Da kommen dann Errors, dass plötzlich Parameter fehlen würden (während bei mysql ohne "i" alles funktioniert). Ich hebe mir das für später auf und bastle jetzt erstmal am dynamischen Einfügen von Zeilen weiter ...

[EDIT]
Ich krieg's gerade um's Verrecken nicht hin, dass meine beiden Buttons zu unterschiedlichen php Scripten führen. Beim "Bestätigen" Button soll das formular.php aufgerufen werden, das dann irgendwann dafür sorgen soll, dass alle Daten an die DB übertragen werden.
Und beim "Neue Eingabezeile hinzufügen" Button soll dynamictable.php aufgerufen werden, das die neue Zeile erstellt.

In meinem html Dokument habe ich folgende Zeile:

<form action="formular.php" method="post">

Also komme ich sowieso erstmal zum formular.php.

Die beiden Buttons am Ende sind so eingefügt:

<div class="submit"><input type="submit" id="1" value="Neue Eingabezeile hinzufügen"></div><br>
<div class="submit"><input type="submit" id="2" value="Bestätigen"></div>

Die Entscheidung, welches php Script nun ausgeführt werden soll, habe ich daher in formular.php reingebastelt:

<?php
    if (isset($id) && ($id == 1)) {
        include('projektzeiterfassung2.php');
    } else {
        include('dynamictable.php');
    }
?>

Allerdings komme ich jetzt immer zu dynamictable.php, egal welchen der beiden Buttons ich drücke ...

[EDIT2]
Jetzt hab ich's:

<?php
    if (isset($_POST['line'])) {
        include('dynamictable.php');
    } else {
        include('projektzeiterfassung2.php');
    }
?>

Über den Namen geht's, nicht über die id. Das muss man auch mal wissen ...

In dynamictable.php schreibe ich jetzt jedenfalls meinen Code rein, der EINE Zeile für die Tabelle erzeugt. Und dabei muss ich dann rausfinden, wie das nun wirklich läuft, dass in dropdowns der Inhalt bestimmter DB-Tabellen angezeigt wird.

[EDIT3]
Langsam nervt's! Jetzt merke ich gerade, dass dann meine neue Zeile nicht im html-File an den Header angehängt wird, sondern dann sinnlos in einem neu aufgerufenen php Script erstellt wird ...

 

[Rho]

Glückwunsch. Entwickelt sich bisher alles ja wie von mir vermutet. Dir Fehlt es einfach an jeder Ecke an Grundlagen. Sei es RDBMS, PHP, Javascript oder HTML.
Ich vermute mal, du hast dir zu dem Thema auch noch immer kein Bucher bzw. Bücher besorgt. Im Internet mal schnell nach etwas Suchen klappt super, aber nur wenn man schon eine Basis hat, auf der man aufbauen kann. Ansonsten führt das ganz schnell ins Chaos, weil man gar nicht wirklich versteht, was man da gerade an Code in sein Projekt kopiert hat.

 

[TessaKavanagh]

Das es mit MYSQLI_* nicht getan ist, sollte eigentlich klar sein. Das ist ja eine geänderten Syntax mit eigenen/neuen Funktionen .