Feenix566

You could use AJAX to populate the second dropdown box dynamically, but I don't think you're looking for a solution that sophisticated. Instead, try this: Make a form that submits to itself, and make the PHP script that creates the form check to see if the variable from the first dropdown box was submitted with the request. <form name='theform'> <select name='type' onChange='document.theform.submit()'> <? $DB = oci_connect("user", "pswd", "db"); $get_types = OCIParse($DB, "select distinct type from product"); OCIExecute($get_types); while($type = oci_fetch_array($get_types)) echo "<option value='{$type['TYPE']}' " . ((isset($_GET['type']) && $_GET['type'] == $type['TYPE']) ? "selected" : "") . ">{$type['TYPE']}</option>\n"; OCIFreeStatement($get_types); ?> </select> <p> <? if(isset($_GET['type'])){ echo "<select name='product'>\n"; $get_products = OCIParse($DB, "select product from product where type = :type"); ocibindbynname($get_products, ":type", $_GET['type']); OCIExecute($get_products); while($product = oci_fetch_array($get_products)) echo "<option value='{$product['PRODUCT']}'>{$product['PRODUCT']}</option>\n": OCIFreeStatement($get_products); echo "</select>"; } ?> <input type=submit> </form>

Run oci_commit() at the end of your PHP script. Keeping a persistent connection alive from within a web server is not an ideal solution, given the request/response nature of HTTP.

TOAD is pretty awesome, too.

Oracle returns all its results in CAPS. So change it to $row['HOUSE_TYPE'] and you should get the data. Also, start programming with your error reporting set to E_ALL so you can see notices about undefined indexes in the future.

I suspect that your class and your calling script are both using the same Oracle connection. Try having your class open up its own connection to Oracle, and keep it private. That way only the class will be able to commit its own transactions.

Well, there is no function called "parse_execute()", so that could be why it's telling you it's not defined. Try OCIParse() and OCIExecute().

$get_doc = OCIParse($DB, "select filename, blobfile from table"); if(!OCIExecute($get_doc)) exit('failed to search for documents'); while($doc = oci_fetch_array($get_doc, OCI_NUM+OCI_RETURN_LOBS)) echo $doc[0] . "\n" . $doc[1] . "\n"; OCIFreeStatement($get_doc);

OCIParse()

There are two ways to do this. If you want to store the date from the database server, you would execute a query like this: insert into table(field)values(sysdate) If you want to store the date from the web server, you would do this: $current_time = date("d M Y H:i:s"); $insert = OCIParse($DB, "insert into table(field)values(to_date(:value, 'dd Mon yyyy hh24:mi:ss'))"); ocibindbyname($insert, ":value", $current_time); OCIExecute($insert); OCIFreeStatement($insert); Of course, if your database and your web server reside on the same machine, it doesn't matter which one you use. It only matters if they're on two different machines and the clocks are off.

Sorry for the duplicate thread, I realized this forum would be more appropriate... I've come across a situation where PHP and Oracle are apparently experiencing a time-dilation effect. I'm writing code for user authentication. We track login sessions. First, it searches for open login sessions, and closes them. Then, it creates a new open login session. Here's pseudocode: <? $get_logins = OCIParse($DB, "select login_id from login where user_id = :user_id and logoutdate is null"); ocibindbyname($get_logins, ":user_id", $user_id); if(!OCIExecute($get_logins)) exit("failed to search for open logins"); while($login = oci_fetch_array($get_logins)){ $update = OCIParse($DB, "update login set logoutdate = sysdate where login_id = :login_id"); ocibindbyname($update, ":login_id", $login['LOGIN_ID']); echo "closing login {$login['LOGIN_ID']}\n"; if(!OCIExecute($update)) exit("failed to close login"); OCIFreeStatement($update); } OCIFreeStatement($get_logins); $insert = OCIParse($DB, "insert into login(user_id, logindate)values(:user_id,sysdate)returning login_id into :login_id"); ocibindbyname($insert, ":user_id", $user_id); ocibindbyname($insert, ":login_id", $login_id, 32); if(!OCIExecute($insert)) exit("failed to create new login"); OCIFreeStatement($insert); echo "created login $login_id"; ?> Now, this doesn't happen every time I run it, only about one in three times. It will actually update the login before it makes it! It prints out the debugging message saying it's updating the login, then it prints out the message saying it made the login, and the login_id's are the same number!!! So when the script is done running, the user doesn't have an open session, and subsequently is asked to log in again. The only explanation I can think of is that PHP is skipping over the while loop because it's waiting for Oracle to return the results of the query. PHP must be executing the code after the while loop, then coming back and executing the loop on the results of the query, which unfortunately includes the record created by the code after the loop. Am I correct? Is there a way to avoid this?

I've come across a situation where PHP and Oracle are apparently experiencing a time-dilation effect. I'm writing code for user authentication. We track login sessions. First, it searches for open login sessions, and closes them. Then, it creates a new open login session. Here's pseudocode: <? $get_logins = OCIParse($DB, "select login_id from login where user_id = :user_id and logoutdate is null"); ocibindbyname($get_logins, ":user_id", $user_id); if(!OCIExecute($get_logins)) exit("failed to search for open logins"); while($login = oci_fetch_array($get_logins)){ $update = OCIParse($DB, "update login set logoutdate = sysdate where login_id = :login_id"); ocibindbyname($update, ":login_id", $login['LOGIN_ID']); echo "closing login {$login['LOGIN_ID']}\n"; if(!OCIExecute($update)) exit("failed to close login"); OCIFreeStatement($update); } OCIFreeStatement($get_logins); $insert = OCIParse($DB, "insert into login(user_id, logindate)values(:user_id,sysdate)returning login_id into :login_id"); ocibindbyname($insert, ":user_id", $user_id); ocibindbyname($insert, ":login_id", $login_id, 32); if(!OCIExecute($insert)) exit("failed to create new login"); OCIFreeStatement($insert); echo "created login $login_id"; ?> Now, this doesn't happen every time I run it, only about one in three times. It will actually update the login before it makes it! It prints out the debugging message saying it's updating the login, then it prints out the message saying it made the login, and the login_id's are the same number!!! So when the script is done running, the user doesn't have an open session, and subsequently is asked to log in again. The only explanation I can think of is that PHP is skipping over the while loop because it's waiting for Oracle to return the results of the query. PHP must be executing the code after the while loop, then coming back and executing the loop on the results of the query, which unfortunately includes the record created by the code after the loop. Am I correct? Is there a way to avoid this?