Subject Re: [ib-support] string guy
Author Helen Borrie
At 05:54 AM 26-04-02 +0000, you wrote:

>This works fine as long as the user doesnt enter a single quote in
>the Company name field. How can the user enter a single quote without
>generating an error?
>Thanks for the responses. I looked at many of the suggestions and
>replacing the single quote with a doulble quote works but it seems
>that php addslashes() ie. adding a slash character before the single
>quote doesnt work with interbase. Its seems actually much easier
>just to not allow the single quote.

You misunderstood the many responses. Nobody suggested replacing single
quote with double-quote. It just happens the apostrophe is the *escape*
character for apostrophes in FB/IB strings. So, when you need to escape a
single apostrophe, you do it by entering two apostrophes.
Two apostrophes <> one double-quote.

>One more question about interbase. Our company is using Paradox and
>moving to Interbase. IN paradox tables or records are
>locked .INterbase supports transactions. I dont have
>a complete understanding of transactions yet. In the situation below:
>begin tran;
>INSERT INTO invoice (...) values (...);
>$parent_id = mysql_inserted_id();
>for each shopping_cart_items
> INSERT INTO invitems (...,invoice,..) VALUES (...,$parent_id,... );
>DELETE FROM shopping_cart_items WHERE cart_id = ?
>commit tran;
>I can see the need for wrapping the transaction. Is this the only
>time you need to use the transaction command when there are multiple
>statements that need to succeed or fail.(all or nothing situation)?

Everything you do in FB/IB happens inside a transaction context...excepting
ONLY the generation of a value from a generator. Even a SELECT is in a
transaction context. In interactive work, your typical transaction
scenario is:

start a transaction if one is not already started
prepare a statement
submit a query and get a dataset back
let users mess about with data (insert, update or delete)
at some point, commit outstanding work
(if commit-with-retain is used in place of regular commits, then do a full
commit from time to time to allow garbage collection to occur)

For batch work,
start a transaction
perform a gazillion updates, inserts or deletes
commit the transaction

In fact, big batches go better if you can split the work into separate
transactions and commit work about every 15,000 operations (just a

FB/IB doesn't employ user locking at all...the engine takes care of
locking, according to the rules you specify for transaction isolation and
locking behaviour. If this is all double-Dutch to you, then you need to do
some research. You might get some value from reading up the TechInfo
sheets on the subject, from the IBO website, There are also a couple of white
papers about it at

Unlike Paradox, FB/IB is a client/server database...the main purpose of
transactions is to give each user an isolated and consistent view of data
for the duration of a task. Part of the engine's transaction management is
to keep an account of which transaction is looking at which view and, when
a user decides to request an update, to decide how to resolve
conflicts. You need to understand *how* it resolves conflicts and set up
transaction parameters to suit the needs of your application.

>So if you are just doing a single statement insert into interbase its
>not necessary to wrap it in a transaction? Is there any other
>situations you need to wrap something in a transaction?

It's the wrong question - you don't get a choice. The client is *always*
in control of starting and ending transactions. If a prepare or commit
fails, then the engine does nothing but report the error. It is down to
the client app to trap the error and act accordingly - by rolling the
transaction back, or some other action that will permit a corrected query
to be resubmitted - user cache, timers, etc.


All for Open and Open for All
Firebird Open SQL Database · ·