kan geen data uit db halen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

SQL Developer / SQL DBA / Financiële instelli

Functieomschrijving Ben jij een ervaren SQL Developer / SQL DBA die houdt van een uitdaging? Heb je ruime ervaring met SQL, SQL Server, SSIS en het bouwen van queries? Lijkt het jou interessant om verantwoordelijk te zijn voor de gehele Nederlandse database omgeving van deze internationale financiële organisatie? Lees dan snel verder! Verantwoordelijk voor operationele werking van de database omgeving voor alle Nederlandse vestigingen; Schrijven van SQL queries; Beantwoorden complexe integratie vraagstukken; Meewerken aan uiteenlopende interne projecten en organisatiebrede migratie trajecten; Requirements opstellen; Fungeren als sparringspartner voor de business. Functie-eisen HBO werk- en denkniveau; Minimaal drie jaar ervaring in een

Bekijk vacature »

Pagina: « vorige 1 2

Yannick decock

yannick decock

12/09/2019 16:55:31
Quote Anchor link
Thomas van den Heuvel

dankje nu snap ik ook inderdaad een beetje waarom

maar stel nu een layout template in je index


bv

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
<?php
require 'includes/dbconnect.php';
require 'layout/header.php';
require 'layout/left.php';
require 'layout/main.php';
require 'layout/footer.php';
?>



als enige in je index en de rest in je php met een check login ?


werkt toch een stuk makkelijker als er dan een fout is zie je toch ook waar meteen dan alles in je index uit te zoeken ?
 
PHP hulp

PHP hulp

15/09/2019 17:06:26
 
- Ariën -
Beheerder

- Ariën -

12/09/2019 16:59:46
Quote Anchor link
Er zijn nog meer truukjes om fouten op te kunnen sporen. Zoals Debugtraces.... :-P
Maar het gaat er ook om dat alles bij de index binnenkomt. Wat als je straks 30 subpagina's hebt voor contact, reviews, informatie etc....

Ga je dan die includes ook steeds per stuk toevoegen? Tijdrovend werk.
 
Thomas van den Heuvel

Thomas van den Heuvel

12/09/2019 17:11:12
Quote Anchor link
Op het moment dat je één bestand gaat gebruiken als kapstok voor de rest van je applicatie dan komen er wel ineens een aantal dingen samen. Je moet dan ook gaan nadenken over de "flow" door de opbouw van de webpagina, als er uberhaupt een opbouw nodig is.

Als je bijvoorbeeld een (POST) formulier aan het verwerken bent dan redirect je na afloop idealiter meteen door naar een resultaatpagina, of terug naar de invoerpagina met foutmeldingen. Je blijft in dat geval dus ook nooit op de deelactie van een pagina waar gePOST wordt. Dit zorgt anders namelijk weer voor problemen wanneer iemand besluit de pagina op zo'n moment te verversen (er wordt gevraagd of de informatie opnieuw gesubmit dient te worden wat mogelijk kan resulteren in dubbelposts en dergelijke). Omdat je meteen na afloop wordt doorgestuurd is het dus ook niet nodig om zichtbare uitvoer te produceren, die deelactie zou enkel de verwerking van het formulier moeten regelen. In dat geval zou de pagina dus ook niets weer moeten geven. De acties van een deelpagina bepalen wat er moet gebeuren, dit ligt niet op voorhand vast.

Quote:
werkt toch een stuk makkelijker als er dan een fout is zie je toch ook waar meteen dan alles in je index uit te zoeken ?

Mocht er ergens in een include iets mislopen dan krijg je nog steeds een zeer duidelijke foutmelding over waar (in welk bestand en op welke regel) dit misloopt. Wat dat betreft zijn PHP-foutmeldingen altijd redelijk duidelijk. Wanneer je een index-kapstok gebruikt zul je dus geen foutmelding krijgen in de trant van "er ging iets mis in de index en zoek verder maar uit waar het misging" :).
Gewijzigd op 12/09/2019 17:13:55 door Thomas van den Heuvel
 
- Ariën -
Beheerder

- Ariën -

12/09/2019 17:15:54
Quote Anchor link
Volgens mij is dit niet bij velen bekend, maar PHP heeft ook een toffe functie Debug_backtrace:

https://www.w3schools.com/php/func_error_debug_backtrace.asp

Als je echt een uitgebreide applicatie hebt, geeft dit een hele back-trace naar met de route naar je fout.
Je kan dit ook in Exceptions gebruiken: https://www.php.net/manual/en/exception.gettrace.php

Uiteraard zijn zulke trace-routes niet bedoeld voor je publiek, dus het is leuk op een testomgeving, waarbij je anders voor publiek een algemene foutmelding toont (Er is bij ons wat mis) waarna je dit ergens buiten je webroot logt ;-)

Pas nog zo iets geschreven...
 
Yannick decock

yannick decock

12/09/2019 19:10:52
Quote Anchor link
hoe moet je dit naar mysqli om zetten ?


Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
$notifyQuery = mysql_query("SELECT * FROM notifications WHERE user='".$data['username']."' AND deleted != '1' ORDER BY ID DESC") or die(mysql_error());
$notifyNum = mysql_num_rows($notifyQuery);
 
- Ariën -
Beheerder

- Ariën -

12/09/2019 19:38:41
Quote Anchor link
Heb je al gekeken naar:mysqli_query
mysqli_error
mysqli_num_rows
?

Voornamelijk een 'i' toevoegen, en de syntax nalopen die wel eens verschilt met vaak een extra connectie-parameter.
Gewijzigd op 12/09/2019 19:39:55 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

12/09/2019 21:41:54
Quote Anchor link
En misschien is dit een goed moment om een soort van database-wrapper te gaan gebruiken om zogenaamde hard coding tegen te gaan, zodat je de volgende keer niet weer voor hetzelfde probleem komt te staan als er weer iets in MySQL-land verandert.
 
- Ariën -
Beheerder

- Ariën -

13/09/2019 00:02:29
Quote Anchor link
Een dergelijke aanpassing van de MySQL-functies is tot nu toe maar een enkele keer gebeurd, en dat was de uitfasering van de MySQL-functiebibliotheek waarbij iedereen over moest stappen naar MySQLi (improved) bibliotheek of PDO.

Een wrapper maakt het wel makkelijk, maar het blijft altijd een kosten/baten verhaal die bepaalt of het zinvol is. Tijdens een toekomstige overgang naar een nieuwere PHP-versie speelt er altijd wel wat meer dan enkel MySQLi-functies aanpassen. En mogelijk worden er in de toekomst ook andere functies aangepast. Ga je dan ook een wrapper bouwen voor de string-functies? :-P En dan heb ik het nog niet over de array-fucnties en zo kunnen we wel een poosje doorgaan ;-)

Voor een open-source pakket waarbij de gebruiker zelf mag kiezen op wat voor database die wil gaan draaien kan ik mij de noodzaak van zo'n wrapper wel voorstellen. Maar in andere gevallen vind ik het 'mwah!'

Ik ben wel een voorstander van het gebruik van het object-georiënteerde MySQLi. Je kan prima gebruik maken van exceptions en de bestaande interne MySQLi-class zelfs uitbreiden via extend met eigen functies of geclonde functies. Bijvoorbeeld centrale errorafhandeling ín je query. Maar ook dit kan je (als je zin hebt) als wrapper gebruiken.
Gewijzigd op 13/09/2019 00:53:07 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

13/09/2019 17:33:08
Quote Anchor link
- Ariën - op 13/09/2019 00:02:29:
Een dergelijke aanpassing van de MySQL-functies is tot nu toe maar een enkele keer gebeurd

Een ezel stoot zich in het algemeen... :)

- Ariën - op 13/09/2019 00:02:29:
Een wrapper maakt het wel makkelijk, maar het blijft altijd een kosten/baten verhaal die bepaalt of het zinvol is.

Natuurlijk, je moet zelf de afweging maken of dit voor jouw applicatie de moeite waard is, maar het is ook gewoon "defensief programmeren". Stel dat je om wat voor reden dan ook op een gegeven moment PDO wilt gaan gebruiken in plaats van MySQLi. Wellicht omdat je meer en andere database-koppelingen hebt en uniform wilt blijven werken. Als je dus in je code netjes, maar rechtstreeks, MySQLi gebruikte, dan zul je dit nog steeds moeten aanpassen. Als je al een eigen laag/koppeling had om deze eindjes aan elkaar te knopen, dan hoef je enkel de implementatie aan te passen, de rest van de code blijft ongewijzigd. Daarmee wordt de scope van zo'n wijziging ook een stuk kleiner en daarmee is je code een stuk flexibeler. Vergelijk het met een laptop met vervangbare onderdelen en een laptop "uit één stuk". Sure, de variant met vervangbare onderdelen is dan wellicht duurder, maar hier doe je dan waarschijnlijk ook langer mee.

Simpelweg de kaart spelen <ik heb hier een triviaal voorbeeld> dus <deze (ingrijpende?) wijziging is niet nodig> gaat niet altijd op... Je moet ook kijken wat het je oplevert, maar je zou op zijn minst de afweging moeten maken.

- Ariën - op 13/09/2019 00:02:29:
Tijdens een toekomstige overgang naar een nieuwere PHP-versie speelt er altijd wel wat meer dan enkel MySQLi-functies aanpassen. En mogelijk worden er in de toekomst ook andere functies aangepast. Ga je dan ook een wrapper bouwen voor de string-functies? :-P En dan heb ik het nog niet over de array-fucnties en zo kunnen we wel een poosje doorgaan ;-)

Ik maak mijzelf geen illusies en wil ook niet doen alsof we hier code voor de eeuwigheid schrijven, maar het lijkt mij wel verstandig om je opties open te houden en jezelf niet (althans niet op voorhand) vast te programmeren. Met een wrapper spreid je risico. Dit geeft je ook ruimte wanneer je na verloop van tijd tot een ander of groter inzicht komt om implementaties aan te passen en/of uit te breiden. Dat is met hard coding toch echt een stuk lastiger danwel vrijwel onmogelijk.

Op dat moment vormt je eigen code de grootste belemmering om dingen aan te passen en daarmee mogelijk te verbeteren, en dat is natuurlijk nooit de bedoeling.
Gewijzigd op 13/09/2019 17:35:02 door Thomas van den Heuvel
 

Pagina: « vorige 1 2



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.