At 04:49 PM 19-02-02 +0100, Morteargenta Giovanni wrote:

>Hi all.
>I'm new to IBO , and in one day i have ported most of a 150.000 lines of
>code with LOTS of tables

Ttables--->TIBOTables will slow down your connections. It will be a priority to migrate your TIBOTables to TIBOQuery and/or other more suitable dataset classes.

Your Paradox tables also, almost certainly, would export structures that don't work efficiently with Interbase, especially across network boundaries. It is also highly likely that you have no legacy indexes which will be useful for InterBase. These are issues for which you should use the ib-support list, not this one.

>and Querys without to much problem (there where
>some issues with Batchmove that are pending , of course) , except some
>things i frankly don't understant

It is preferable to post ONE topic per thread, otherwise it becomes a nightmare to keep in synch.

>The foremost importat for me is that I have the connection to database
>floating , depending on the installation where I deploy the program , and
>used a combination of alias in the BDE and a plain text file to locate the
>main configuration database in the remote server on the installation. So ,
>the DatabaseName is got something like this
>
>Read the Get the Database Change the parameters
>Select DataDB configuration
>text file in -> complete path -> in the DBConf alias to ->
>Params from a table in DBConf -> Fire up app.
>client (with server included) point the DBConf DB
>And set the DataDB alias parameters

What is DBConf? a text file? What do you mean by "the DBConf alias"?

>Now , i got from a wait time of 15 seconds to a wt of 76 seconds in IBO..
>bad thing.

There are several causes of slow connection, none of which has anything to do with IBO:

(1) Starting your application with all datasets open.
(2) As (1), with a lot of Table components in your application.
(3) A tcp/ip connection that is not configured properly on the client.
(4) Competition on the client for network resources

You seem to have ALL of them.

There are a couple of IBO-related ones, too, which will be noticeable if you are using a lot of table components.

>After carefull search , that turned up to be that , no matter what i said to
>the Connections in the datamodules about predeterminated servers , default
>paths or (God forgive me) BDE alias configuration. The Connection component
>was always trying to connect to a local database server instead of the one i
>especified in the server property.. until i tested in design time to set
>connected to true , and then , to false. After that , connection was slow
>(30 sec , twice the time of bde!!!) , but it worked.

Get rid of the BDE Alias property - its purpose was simply to help you during conversion by picking up the database connection properties from your IDAPI config. IMO, it causes more problems than it solves. In your case, it is worse than useless because the application does not have a hard path set when it opens.

>I know that i have to polish really hard the application to a total port ,
>but for now , there seems not be the acceleration promised in the web site.
>I'll keep trying , but some help would be appreciated.

No: IBO is not a magic bullet to make an InterBase application behave like a typical Paradox one. On the contrary, it is designed for server-centric development (as compared with the BDE, which is for the client-driven architectures required by file-served databases). As you observe, you have much "polishing" (+ scrubbing + pruning) to pull your desktop-style application into shape for client/server work.

You might get some ideas by downloading and reading the white paper on Moving to Client/Server, from the IBO TechInfo page. And DO keep asking questions - many people in this list have been along your road before. :))

>Another question is : Are the QuickReport Pro components througthly tested
>against heavy duty IBO abuse ? So far by now i has been unable to make them
>rum in armony.. but patience , i'm only a day old in IBO using...

Tested against abuse? No, not as far as I know.
QuickReport behaves in a TIBO* application just as it does in a VCL application. However, now that you are using a database that places tasks under transaction control, you will need to address user-concurrency issues. In the place you are at now, I suggest that you first address the dataset issues, since your performance and access problems won't go away until you do.

>I was using D6+IBO4.2Fp+QuickReports3.5.1(Win98-2ndEd)+IB5.6(Linux)

Some (off-topic-for-IBO) things you can do to improve connection speed for TCP/IP Windows clients:

- Set up the Server and its IP address in the HOSTS file on the client machines.
- Get rid of IPX from your network entirely
- Get rid of NETBEUI if you can, otherwise relegate it to the bottom of the protocol list
- Use ping to test how fast the NIC is connecting to the Linux server. The difference between the first ping-return and the connection-time for your client application will be caused by "noise" in your application code. Your aim should be to clear out all stuff that your application is causing at the OS and NOS levels to slow things down.
- Make sure that the delays are not being aggravated by your Linux server machine going into Sleep mode when there are no active connections. I've disabled Sleep at BIOS level on my Linux machine to avoid this problem.

..and keep asking...just one question per new thread, please.

regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at www.ibobjects.com