--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 10:01 AM 29/01/2008, Federico Bobbio wrote:
> >> -- Is this a single-user, stand-alone system?
> >> -- Is it 2-tier client server or n-tier? If it is 2-tier then
> >remote clients cannot access a database through localhost...
> >
> >
> >At this time is a single user in one computer, really simple, but in
> >the future it should grow.
> >The business and presentation tiers are managed in the client side (if
> >i get you right)
>
> Accessing databases as a local user via localhost is not a great way

to develop a 2-tier fat client system that you intend to deploy for
multi-user use. Since you are using XP, develop from a remote desktop
client and use the node name of the server in your TCP/IP string. (IP
address is also possible, if you can be certain that, when the system
is deployed, you can be certain that the IP address will be statically
defined.)

Yes you're right, i get what you're saying here :)

>
> >> Tell us more about "user disconnecting from the server".
> >
> >I'm developing the app and i didn't give it to the customer yet, so
> >i'm the only user right now, the problem is that i can't make it work
> >fine :(
>
> You can, however, develop and test it as a remote user. "Remote"

means "in the same network as the server host, but on a different node".

>
> >> >and a problem with the used SQL.
> >>
> >> How long is a piece of string? Bad SQL can make response slow but
> >it wouldn't directly cause a client connection to break...
> >
> >As i said i'm not an experienced user so i'll tell you how i'm working
> >with SQL. For example i have an Employeers table and they hava Phones
> >(table) and Addresses (table) and when i need to get the data i open a
> >connection to get the info from the Employeers table, inside of this
> >connection i open another for the phones and another for the
> >addresses, is this as bad as it sounds? :P
>
> Yes, even worse. :-(

Ouch :(

>
> >The querys are like "SELECT <COLUMN_NAMES> FROM <ONLY_ONE_TABLE> WHERE
> >EMPLOYEER_ID = X", this is just an example, there are no more than 10
> >or 12 columns in the bigger tables
>
> It's not primarily about the size of the tables. SQL is a *query

language*, which means it is designed to let you retrieve SETS. Your
SELECT list and your WHERE clause determine (respectively) how many
columns and how many rows are in your sets. When you go into a
deployed client/server situation the size of the sets becomes a lot
more important than it is when everything is happening on a single
machine!

Good point, think i was going to a certain death :P

>
> >> >Could the problem be that when i need data from multiple tables i'm
> >> >opening a lot of connections to get it?
> >>
> >> Yes. The client should have one connection per thread and the work
> >within one thread should never refer to other connections or to
> >transactions and statements in other connections.
> >
> >So i need to separate the connections in different threads or should i
> >bring all the data i need in one big query?
>
> Hmmm, instead of trying to answer that question, perhaps it is

better to try to get you to understand the concept of a "session".

>
> "Session" is a client-side concept that represents the model of "a

user application" connecting to "a database". In your fat client, you
have:

>
> 1. Your client application code that runs on the client machine.
>
> 2. The Firebird API, which is loaded on the client machine as a

library that exposes all the functions, macros, etc. that are needed
for the client application to communicate with the Firebird server.
On a Windows client machine, its name is fbclient.dll. On Linux SS,
it is libfbclient.so.

>
> 3. Between the client application and the Firebird is a data access

layer, such as a driver (e.g. Jaybird for Java, an ODBC driver, a .NET
driver, a PHP or Python library, a set of Delphi components, a set of
wrapper components such as IBPP for C++, and so on).

>
> At its simplest, a "session" is one client that has made one

connection to one database using one Database Parameter Block (DPB),
having called one or more appropriate functions of the API. Each
different, client-language-specific data access layer (see 3 above)
has its own way to wrap up the DPB and the required API calls. Your
application would call these wrappers and is not concerned about what
the wrapper code does beneath the surface. When this call succeeds,
you have "a connection".

>
> Within the connection, you have transactions. A transaction

isolates one block of work in your application from another block of
work. It also isolates its "view" of database state from the "view"
seen by any other transaction. That goes for different transactions
within this session, as well as transactions within other sessions.

>
> Within a transaction, you have statements. Each statement is

isolated within one and only one transaction. A SELECT statement
returns a SET to a buffer at the server. Rows from that buffer are
fetched on request *within* the current execution of the statement and
within the current transaction. Statements that are not SELECTs
return data directly to the calling transaction.

>
> So, to summarise the simple picture, a session consists of:
>
> 1 connection
> a transaction
> [one or many statements pertaining to that transaction]
> [one or many sets and other results pertaining to that

transaction]

>
> another transaction
> [one or many statements pertaining to that transaction]
> [one or many sets and other results pertaining to that

transaction]

>
> another transaction ..... etc.
>
> >Is a simple application for a company that sells medical products, it
> >should manage only information about the statistics of the sales.
>
>
> >So i need to separate the connections in different threads
>
> Separate connections must be in different threads. Each connection

must comprise a totally isolated session (its own transactions,
statements, sets, etc.)

>
> > or should i bring all the data i need in one big query?
>
> That's the wrong question to ask. For all of the data that the user

needs to work with, all of the sets (output of SELECT statements) and
executable statements (insert/update/delete) needed for a single task
should be defined within the context of a single connection |
transaction. If you make separate *connections* for each statement
and then try to "hook them up" you will have access violations in the
client. When the client crashes, the connection to the server is
broken and you get the 10054 (and other) network errors that you are
seeing.

When i said "one big query" i meant: use join as Ann told before,
would that be right?

>
> So, yes, I think at this point there is a LOT that you are missing.

I strongly advise that you subscribe to the support list of whatever
driver you are using for your data access layer and get some direction
on how to manage the connections, transactions and statements in your
client application. Visit http://firebirdsql.org/index.php?op=lists
to find the right list.

Ok i'll be taking a look to the jaybird mailing list and trying to put
what you taught me today to work :)

>
> To make it easier for the people whom you want to help you, please

click the ASK SMART link at the top of that page and study the linked
article, "How to Ask Smart Questions". It's essential for everyone
who hasn't used support lists before...

>
> ./heLen
>

Thank you very much Helen!