At 08:58 AM 10/02/2005 +0000, you wrote:

>HB> -- is the report running in a Read Committed transaction?
>
>Would that be good or bad? Was running in a read-only transaction
>(parameters are simply set to "read")

The two options are Read Write (the default) and Read only. Read only would
be isc_tpb_read in the transaction parameter block. If you included the
word 'read' in the list of transaction params, it would at least be
consistent with the way IBX allows you to specify IBTransaction.Params,
i.e. chop off the "isc_tpb" part of the symbol name.

>Added in "read_committed" as
>well, but then started to get locking errors when simultaneously
>editing a record that was getting queried.
>
>HB> (should be in a
>Concurrency transaction, for integrity of the reports, as well as
>reducing the overhead and memory usage.)

OK, I didn't suggest that you should make it read committed - that's why I
went on to explain that it needed to be in a concurrency
transaction!! Since IBX doesn't have a property for transaction isolation
(which is what read_committed and concurrency are) then the word
"concurrency" in the list should do it.

>I have read this section in your book, and in the Interbase 6 docs,
>and some other web links, and now I am more confused than ever.
>I *think* I know what I want, but none of the docs explain what
>actual parameters the setting correspond to. (I am using IBX
>controls, not sure if the syntax would be different at all?) Any idea
>what the syntax is for specifying a concurrency transaction?

In the TPB the symbol is isc_tpb_concurrency. IBX is pretty "raw" - it
doesn't expose the transaction parameters as properties but just documents
them in the help text as "refer to the API documentation." Then, in the
API documentation of course it only tells you what the symbols
are. Actually, transactions in IBX are undocumented. Bill Todd's article
at the IBPhoenix site might be of assistance here, where documentation fails.
http://ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_ibx

Looking at the IB 7 help,

>And will that produce locking issues?

If the transaction is read-only and concurrency, it won't produce any
locking issues.

>NB. The read/writes transactions' params are set to:
>read_committed
>rec_version
>nowait

Fair enough. But you don't need or want these settings for a report.

>HB> -- is the report's transaction a Read/Write one? Make it Read
>Only,
>HB> so
>that reading the data for the report doesn't cause a big build-up of
>garbage from the other users.
>
>See above - set to "READ"
>
>Most of the transactions started, that did not modify anything, were
>getting rolled back, instead of committed. Am busy changing them all
>to Commits.
>The tests we run though, are usually on freshly restored data, so
>that may be an additional factor at the clients site, but not on our
>tests here.

Yes, you'll need to see what's happening in the actual databases, not on
squeaky-clean restored databases.

>HB> If you have a server with SMP and are *not* running Classic, you
>could try it out. The server should try then to balance the load:
>it's quite likely the report will run on the other processor if the
>interactive users are already flat-out when the report's transaction
>starts.
>
>We are using SuperServer.
>Tried Classic here on our single processor 800MHz PIII (win2K).
>Report now uses almost 100% CPU (takes a bit longer to run) but the
>*FABULOUS* thing is that now additional users doing the data capture
>type stuff, don't even realize that the report is running! (We
>all
>did a happy dance around the office - as an accounting bunch, that's
>quite out of character!)
>
>But now we're confused (AGAIN!)
>SuperServer is *SUPPOSED* to be faster on "newer" hardware, and is
>supposed to be the improvement on Classic. And Classic is better on
>multiprocessors (new technology!) So what kind of hardware *IS* it
>going to be quicker to run SuperServer on? How do we know when to
>start using it again?

If you have to run this 80-page report several times a day, why on earth
would you want to go back to Superserver? You have pretty old hardware, a
handful of users and a horrendous report dominating your
existence. Perfect for Classic. Add as much RAM as the server can take
and you'll be in perpetual heaven. Database servers love RAM.

The reason Classic is better for SMP machines is that client processes are
not threads of a main process but are each processes in their own
right. Therefore the operating system send a process to whatever CPU has
some capacity available. With Superserver (one process with a thread for
each connection) Windows doesn't see the connections as finite pieces of
work it can shift from one CPU to another, so it shifts the whole lot -
hence the "see-saw" effect.

>2nd Issue with Classic
>The services manager has not been fully implemented. I can't do a
>backup from a client machine. This is a *BIG* problem. (I'm hoping
>I'm doing something wrong and that it IS possible!)

Most of the Services API is implemented for Classic on Windows. However,
if you are using IBX or IBConsole, it will try to tell you that it's not
implemented for Classic. (Borland doesn't have a Classic for Windows. IBX
is a Borland product that is deliberately not Firebird-aware). Your app,
as compiled for Superserver, should be fine as long as you take care that
clients are using the proper Fb 1.5 "compatibility" client generated for
IBX (you can run instclient.exe on the server to get a copy - see
instructions in the readme named "README.Win32LibraryInstallation.txt" in
Firebird's doc directory.)

./heLen