errore con mysql insert in PDO

[3_g]

grazie di tutti i consigli... ma credo che mi stiate sopravvalutando... implementare quello a cui vi riferite prevede una competenza che al momento non credo di avere (sicuramente andrò a vedere di cosa si tratta)
questa sera/notte farò ulteriori prove sostituendo le "virgolette" (non riesco ancora a gestirle bene... ma neanche in asp ci riuscivo)

però una cosa l'ho scoperta...

101|"Nome Cognome"|"citta"|1|0.0|5|1
102|"Nome Cognome"|"citta"|2|0.1|4|1
103|"Nome Cognome"|"citta"|3|0.2|3|1
104|"Nome Cognome"|"citta"|4|0.3|2|1
105|"Nome Cognome"|"citta"|5|0.4|1|1

questo tipo di dati non crea problemi... mentre questo... si

101|0|"Nome Cognome"|"Citta"|1|0|0|0.0|0|0|0.0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|1

dopo innumerevoli prove sono arrivato alla conclusione (mi riprometto di rifarle con la sistemazione delle virgolette) che il problema non deriva dalla struttura della tabella e/o tipo di dato l'errore viene generato dall'ultimo campo dell'ultima riga del file di testo... strano è...

infatti se inserisco 10 righe, nella tabella ne ritrovo 9... se al file inserisco ulteriori 10 righe, nella tabella ne ritrovo 19 (quindi non è la 10^ riga a dare errore... dall'errore proposto pare ci sia un "problema" di "integer"

  $database->bind(':var10', (int)$var10);

ma se "forzo il tipo di dato in questa modo (giusto... non credo)... non c'è più l'errore ma nella tabella invece del valore 1 c'è 0

la telenovela continuerà questa sera/notte

 

[macus_adi]

ok, quindi @marino51 mi dici che l'utilizzo di eloquent è irrilevante in quanto riesci a mappare e catturare tutte le eccezioni...
Mi sta bene per il metodo tuo, il custom code, la conoscenza del proprio codice, ma....
Stiamo parlando di Laravel no di Webiny, sarebbe come dire "non comprarti l'audi ma una fiat, dopo modificala perchè fa la stessa cosa dell'audi....".
Scusa l'osservazione, non voglio scatenare l'inferno, ma 2/4/10 metodi affinarli a Eloquent mi sembra un pò troppo esagerato nonché spocchioso...

 

[marino51]

Scusa l'osservazione, non voglio scatenare l'inferno, ma 2/4/10 metodi affinarli a Eloquent mi sembra un pò troppo esagerato nonché spocchioso...

in realtà non compro ne audi ne fiat,
suggerisco di costruire in proprio, soprattutto lo suggerisco a chi sta imparando, perché così acquisisce molte più conoscenze
poi tranquillo, leggo sempre con curiosità i tuoi post,
dove sono citati molti frameworks, tools e librerie,
ma post poco utili alla soluzione immediata del problema a cui tiene chi scrive nel forum
quindi non esagerare con le citazioni e non mostrare solo la spocchia delle tue conoscenze ( per titoli ? )

ti é dovuta 1 sola risposta, non aspettare altro
at salut

 

[Max 1]

[OFF TOPIC]
@marino51 e @macus_adi
Mi sapete dire perché fra vuoi due c'è sempre dei battibecchi?
[/OFF TOPIC]

 

[3_g]

spero che queste "divergenze di vedute" non vi allontanino dal post... perchè ci sono interessanti novità... che andrebbero spiegate...
iniziamo dall'inizio...

c'è incongruenza tra apici, usa virgolette per delimitare la query e gli apici per i valori interni ad essa,
vedi suggerimento prova 1

corretta la query, come suggerito... il risultato non cambia
Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field22' at row 1

e allora guarda che ti riguarda se ci sono delle differenze tra i due file di testo (quello semplificato, che funziona, e quello originale)... in fondo il tipo di dati è uguale i separatori anche... ma c'è sempre quel problema dell'ultimo dato sull'ultimo campo...

BEH NON CI VOLEVO CREDERE... nel file semplificato mi era "sfuggito" un invio a capo (cioè c'è una riga vuota alla fine del file)

inserito quello anche nel file originale lo script non va più in errore... e tutti i valori vengono inseriti correttamente

ora mi piacerebbe capire perché?? c'è un motivo??

 

[marino51]

nel file semplificato mi era "sfuggito" un invio a capo (cioè c'è una riga vuota alla fine del file

il "carriage return - line feed" sono i separatori di riga, che permettono la gestione del file riga x riga
leggendo il contenuto del file in esadecimale, sono rappresentati rispettivamente dai caratteri "0D 0A",
in PHP li trovi come "\r\n"
quando l'ultima riga non é chiusa da questi caratteri, viene gestita per via dell"EOF" end of file
e quindi il comportamento (risultato) dipende dalla sequenza delle operazioni nello script

come dire, " keep it in mind ! "

 

[3_g]

...e si può effettuare un "controllo", via script, per verificare che sia presente il fine riga in modo tale da evitare l'errore??

cioè, vista l'impostazione dello script... lettura riga a riga del file di testo come si può verificare se tali caratteri sono presenti alla fine della riga che si sta leggendo ed eventualmente inserirlo/gestirlo?

 

[macus_adi]

http://php.net/manual/en/function.str-getcsv.php

for($i=0; $i<count($textarray); $i++)

$rows=str_getcsv(file_get_contens($file),"\r\n");
//dichiaro all solo per comodità;
$all=[];
foreach($rows as $item)$all[]=str_getcsv($item,"|");

Il tuo parserino csv bello che pronto... Il controllo viene fatto automaticamente aiutando il dev, come fosse una lib esterna!

 

[marino51]

certo che hai modo di controllare,
quando hai letto la riga e hai "caricato" i singoli valori in un'array,
conta gli elementi di quest'ultima "count($array)", se il loro numero non é quello che ti aspetti,
la riga é errata …
in questo modo evidenzi anche le righe "anomale"
scusa se uso un esempio da vbscript, l'ho sottomano e lo capirai perfettamente

v=split(fileline,";")    ' riporta gli elementi in una array

if ubound(v)=14 then    ' ne controlla il numero

scusa se ho risposto ora ma mi hanno interrotto e nel frattempo hai ricevuto un altro suggerimento

 

[3_g]

vi ringrazio per i Vostri preziosi consigli... che cercherò di mettere a frutto (già questa sera)

e quando inevitabilmente mi incarterò...