is it delphi doing this 3

[earlrainer]

I am not sure whether delphi or sybase is the source of my problem,but anyway here it goes.....

I have this program in delphi which accesses a sybase database.
Now the exe and the database both lie on the server and the users access the program from their machines.
There is no problem if two users are logged in and are using the program at the same time.
However the problem comes up when third user tries to login.
The program on his machine seems to go in a hang mode...and nothing happens for even about half an hour.
However if one of the other user logs out ,then the program on the third users machines starts to work properly.

I am not sure if this is a sybase problem or something to do with the BDE configurations in delphi.
i am using a database component with some tquery/datasource components in my program
I am sure atleast one of you must have faced this problem sometime.......
so guys please help .........

 

[svanels]

I suppose that the exe file is on a shared directory. Take it out and put it on the user's computer.

In the BDE configuration indicate the name of the server and the directory where the database can be found.

Regards
Steven van Els
SAvanEls@cq-link.sr

 

[earlrainer]

Hey thanks Steven,
but i am afraid i am not very familiar with the BDE.

i just opened the BDE administrator and what i saw over there was all greek to me.

can you please explain to me in detail exactly where i can enter the name of the server and directory of database.

do i write them somewhere in the databases tabsheet or the configuration tabsheet of the BDE administrator

Bye

 

[LucieLastic]

Are the users editing/changing the data or just viewing? Are you finding stray .MB files in the exe's directory? if so, see last paragraph.

I currently have one exe on a server accessing a Sybase database but the users only have viewing access to the database, we haven't had any problems. Don't think the BDE creates .MB files for simple querying.

Stray .MB files: My last big application was running on a terminal server with SqlServer 7 and I had strange behaviours when more than 2 people logged on to it. The problem was when the users started writing to the database and the BDE was created temporary .MB files with the same names - the different instances of the app were getting confused. To get round this, I created unique directories for each user and assigned the dir of the TDatabase comp, to the user's created dir. The BDE would write it's .MB files to the users' dirs. When they exit their dir was deleted. Word of warning, if the app or server crashes, these dirs would remain so I made them unique by using the username and the date and time(to the second). If any crash occurred, I just went in and deleted the dirs. There may be another way to get round this, but I don't know it - would be interested to learn if there is though.

Hope that helps.

lou

 

[svanels]

I am not familiar with Sybase, but I assume it is a client-server system.
In a typical environment, the application front-end, the .exe file should reside on the user's computer, and the the database with server (sql, sybase, interbase) somewhere else.
Trying to use these systems like a shared applications is looking for problems.
Can you describe the alias that is connected to the sybase database? Steven van Els
SAvanEls@cq-link.sr

 

[LucieLastic]

My Sybase app uses an ODBC driver to connect. An alias is set up on each PC.

Good thing with having the .exe on the server is when it comes to updating it. Also, if you do want to run the app on a thin client, you have to have the .exe on a server - the alias is set up on the terminal server aswell and not on each pc. About the app. that created user directories at runtime, there was only one .exe and upto 50 users logged on at once - no problems occurred regarding access to the app and the db.

lou

 

[rpirvined]

Hi guys,

This seems to be the problem I also have. I have the .exe on the client machine and the database on the server, configured just as it should be, aliases, parodox drivers, no stray .MB files.

I really don't know what to look at next. Any help would be appreciated.

Thanks
David

 

[LucieLastic]

hi

I would try creating the temporary directories for each user and assigning them to the TDatabase component. Will only take a few lines of code. Then see if it gets rid of your problem.

The MB files are left if a query 'crashes'.

I'm sure the temporary directories would solve the problem.

lou

 

[cvgalante]

I thought I heard mention of Terminal Services. Is everyone logging in as the same user? If it is possible to log in using different user names and use the MyDocuments folder as the startup folder (or other user-dependent folder), it might help.

If not using Terminal Services, try creating an icon for each user that has a working directory on the local machine instead of just navigating to the .EXE and starting from Explorer.

Carl

 

[LucieLastic]

hi Carl

Good idea using the MyDocs dir on the terminal server.

If not using a terminal server, I personally wouldn't bother with trying to involve the local machine with working dirs etc. Best if all the work is done on the server.

With the temporary dirs, create these on the server, eg in the exe's directory by extract the applications dir and add to that. Don't need to bother with knowing drive mappings etc too.

lou

 

[rpirvined]

Thanks for the ideas, very much appreciated.

We're not running Terminal Services and each user has their own logon. When the user who has the problem logs on at another machine the problem disappears

I've also just checked the various client machines to see the differences in them as it appears to only happen to one machine. The other machines are all NT Service Pack 5 (same as server) but the offending machine is SP6a.

I have a spare SP5 machine which I am going to let the user try. If it works (long shot perhaps)I will be very happy. And will let you know.

Thanks again.

 

[rpirvined]

Hello again guys,

Just to keep you updated, the user has now been using the SP5 machine for a few days and no problems since then. It is set up exactly the same as the offending machine except for the service pack, so I'm pretty confident that is the problem.

Once again, thanks for the help.

David