roydude

FINALLY SOLVED!!! Okay - so in case anyone's stuck on this ... I noticed that the main PATH environment variable on the server contained paths to some applications I didn't need. I tidied the PATH environment variable up to be as clean as possible, pointing only to what I knew I needed (in the order I wanted it to look in). booted the server and hey presto it worked!!! I'm now documenting the heck out of what the setup of the server is and I'll be monitoring any path changes!

Well we doubled the size of RAM from 1Gb to 2Gb to no avail - still getting the 01019 heap memory issue! I know that increasing RAM doesn't necessarily increase the heap, but I was hoping it'd cut down on hard page swaps, maybe with a knock-on effect to the heap ... Anyway, this thread's getting a bunch of hits with no suggestions - I'm now only left with the option of rebuilding the server (without knowing if this will happen again!), so if anyone has any ideas please post 'em!

Hi Balasun, This is an old topic, but I thought I'd post a reply in case someone needs it at some stage. At a guess I'd say you need to use a date format mask around the date you're supplying - to_date('21/02/2009', 'DD/MM/YYYY')

Hi, I maintain an internal website which accesses Oracle 8i databases using php 5.1.5 via the ora_* extensions. It's worked without issue for about 6 months, but last week started throwing ORA-1019 errors whenever a database connection was required . The oracle help page for this is: ORA-01019: unable to allocate memory in the user side Cause: The user side memory allocator returned error. Action: Increase the processes heap size or switch to the old set of calls. On the web server, I can access oracle via SQLPlus or TOAD without a hitch, it's only a problem when php tries it (even if I execute the php code via the command line). I've increased the heap size from 512k to 3072k (at 512 steps), rebooting the server each time and it's made no difference at all. I've even changed the virtual memory settings from the automatic 1534M to 3072M, again with no improvement. I'm really struggling to come up with ideas - I've no idea what's changed between it working and it failing last week. I've got a memory monitor showing me that 70% of RAM is free (and cpu generally sits around 10%). Basically I can't even hazard a guess as to why it would complain about heap size - and I can access oracle via everything else, just not PHP all of a sudden . Any help welcome - as you can imagine 1 week of inexplicable downtime for this area of the website with no progress at all is a bit woesome! (Before you say it - switching to a newer version of Oracle isn't an option ... and wasn't a problem until last week )

Hi, (This might get a little long, but please bear with me - it took a long time to find the problem with this, so I'm posting it all over the place in case someone needs it!!) I've just spent almost an entire week trying to get PHP to load up php_oci8.dll without falling over immediately - the last two days there's been 2 of us looking at this and we finally came across the answer at about 7pm last night! The problem was: type "php.exe" from a command prompt (this is for a data daemon which needs to run in the background - not a web page!). A window would pop up complaining about OCIStmtPrepare2, saying it could not be located in OCI.dll, and the command prompt would return the message that the "specified procedure could not be found". NOTE: This is not a web server / IIS / Apache issue because we're running from the command line (the pc we finally got this working on doesn't even have a web server on it!)!! We already had Oracle client 10g installed (company standard installation, which works with TOAD, SQLPlus etc... on 10g databases) After around 40 man-hours of installing different versions of php, downloading different versions of OCI.DLL, trawling through forums and websites we finally came across a page that suggested our Oracle 10g client version was incompatible!! To check this, we installed Oracle Instant Client (which is Oracle11) on a different pc, plus PHP 5.2.8. Uncommented the php_oci8.dll and just typed "php.exe" from the command line - it worked!!! ... well, it didn't fail! ;o) .... So in a nutshell, we've currently got it working with: [*]PHP 5.2.8 with the stupidly named php_oci8.dll uncommented, and [*]Oracle 11 client. Now we need to see if the Oracle 11 client will talk to our 10g databases, else we'll need to find a newer version of Oracle 10g client!