Subject | Re: [firebird-php] Inserting NULLs as parameter |
---|---|
Author | Jochem Maas |
Post date | 2008-04-14T15:20:02Z |
Jiri Cincura schreef:
is little that can be done about it (unless you want and can hack the relevant source) ...
there is no active maintainer for the firebird/interbase extension.
an alternative 'solution' might be to wrap the SQL up in a stored procedure
and let it take care of figuring out whether it needs to generate an ID. this
removes the requirement of the -999 hack and also hides the workaround in the database
(I find such workarounds less painful when I don't have to encounter them in my code
on a daily basis ;-)
also note that the 'INSERT OR UPDATE' SQL has an issue that you might not have though
of (and that therefore it might be worth considering split INSERT and UPDATE logic into
seperate 'bits' with seperate SQL):
Person A begins to edit Item with id of 1
Person B deletes Item with id of 1
Person A submits to changes to Item with id of 1
... when the submit happens one assumes that an update will occur, but instead
an insert occurs and the item that was deleted no exists again ... is this desired?
> On 4/14/08, Helen Borrie <helebor@...> wrote:ok, so the php firebird extension probably does it wrong - that sucks but there
>> It's not the same as yours, Jiri, but it is correct. You have only two (or three) ways you can do this:
>
> Correct yes. But with this I'm not able to do same thing as with my
> first statement.
>
>> Then always assign -999 to the param for id. (I don't like this one but it does work...)
>
> This exactly what I'm doing right now. But it's not so clear as it can
> be, when PHP driver will behave like normal dumb console. :(
is little that can be done about it (unless you want and can hack the relevant source) ...
there is no active maintainer for the firebird/interbase extension.
an alternative 'solution' might be to wrap the SQL up in a stored procedure
and let it take care of figuring out whether it needs to generate an ID. this
removes the requirement of the -999 hack and also hides the workaround in the database
(I find such workarounds less painful when I don't have to encounter them in my code
on a daily basis ;-)
also note that the 'INSERT OR UPDATE' SQL has an issue that you might not have though
of (and that therefore it might be worth considering split INSERT and UPDATE logic into
seperate 'bits' with seperate SQL):
Person A begins to edit Item with id of 1
Person B deletes Item with id of 1
Person A submits to changes to Item with id of 1
... when the submit happens one assumes that an update will occur, but instead
an insert occurs and the item that was deleted no exists again ... is this desired?
>