---

Hej

Hvad kan jeg stille op med dette problem? Jeg spiller op mod ORACLE og
vil indlæse fra en formular på en hjemmeside. Efter indtastning får
jeg f.eks. den query:

$query = "INSERT INTO HJM.BRUGER
VALUES (134231,
'Test firma',
'KUNDE',
'torre@mail.dk',
'testbruger',
'testkode')";
$result = oci_parse ( $conn, $query ) or die ( 'Can not parse
query' );
ociexecute ( $result, OCI_DEFAULT ) or die ( 'Can not Execute
statment' );

Problemet er at intet tilsyneladende bliver indsat i DBasen!? Og jeg
får ingen fejl! $result angiver som den skal en gyldig Resource id #9
og ociexecute() svarer tilbage med værdien 1. Ingen fejl.

BRUGER-tabellen som jeg læser fra min sql Developer indholder ikke den
ny kunde, men hvis jeg tager nøjagtigt den forespørgsel som jeg lige
har produceret og kører den i Developeren, så indlæses den! How come?
og hvad kan jeg gøre for at fejl-finde?

Jeg skal tilføje at rettigheder til webbruger er sat og bliver anvendt
både på web og i Developeren. Nøjagtigt den samme operation lykkes
fint andre steder i programmet på andre tabeller.

Er det noget med commit og rollback? Jeg er totalt kørt fast :S
Med venlig Hilsen

---

"Torben" <ringsoe@gmail.com> skrev i en meddelelse
news:42f18091-91dc-463e-a3cb-b2f41ef62cb4@a1g2000hsb.googlegroups.com...
[snip en masse om en oracle insert into]
>og hvad kan jeg gøre for at fejl-finde?

Du indsætter en "select" lige efter din insert. Din select skal selvsagt
select'e lige nøjagtig den row du tror du har fået indsat. Hvis den kan
selectes så findes den i basen (i den session), og så har du nok et commit
problem.

Carsten

---

> Du indsætter en "select" lige efter din insert. Din select skal selvsagt
> select'e lige nøjagtig den row du tror du har fået indsat. Hvis den kan
> selectes så findes den i basen (i den session), og så har du nok et commit
> problem.

Det var ikke et commit-problem. Jeg vil huske at bruge din metode hvis
jeg igen kommer til at sidde en lignende situation. Det viser sig at
'OCI_DEFAULT' er et problem - hvorfor ved jeg ikke rigtigt. Når den
parameter er væk indlæser den data som den skal!

Tak for dit forsøg
Torben

---

"Torben" <ringsoe@gmail.com> skrev i en meddelelse
news:7cbcf8f2-89ac-419e-820c-860d627b9035@l64g2000hse.googlegroups.com...
> Du indsætter en "select" lige efter din insert. Din select skal selvsagt
> select'e lige nøjagtig den row du tror du har fået indsat. Hvis den kan
> selectes så findes den i basen (i den session), og så har du nok et commit
> problem.

>Det var ikke et commit-problem. Jeg vil huske at bruge din metode hvis
>jeg igen kommer til at sidde en lignende situation. Det viser sig at
>'OCI_DEFAULT' er et problem - hvorfor ved jeg ikke rigtigt. Når den
>parameter er væk indlæser den data som den skal!

Så er det problem netop et commit problem ! Den parameter bestemmer nemlig
hvordan dine sql'er bliver commit'ed. Prøv at kigge lidt her:

http://dk2.php.net/manual/en/function.oci-execute.php

Specielt teksten omkring "mode". Her står (bl.a.)
When using OCI_DEFAULT mode, you're creating a transaction. Transactions are
automatically *rolled back* when you close the connection, or when the
script ends, whichever is soonest. You need to explicitly call oci_commit()
to commit the transaction, or oci_rollback() to abort it.