Connectivity Issue in client server setup

[karthik]

We are using client/server setup to access TD applications from the client machine. The client machine is a thin client where we have only the short cut for the application which is installed in the server Also the client has drive mapping with the server to run the applications installed in the server. The server machine is configured with ODBC connection(to connect to sql server dbs) and sql.ini containing the odbc entries. the issue is when we try to login to the application from the client machine the system is looking for the odbc entries in the client machine instead of using odbc entries configured in the server. If we configure the odbc entries in the client machine then the applications are connecting from the client machine.
our customers are complaining that due to their IT Security policies ODBC entries are not allowed in the client machines. Please advise how to make the system work from the client machine without using any odbc entries in the client machine and using it from the server since all the applications and sql.ini are residing in the server.

[RainerE]

We have a similiar scenario execpt that we use OLEDB instead of ODBC.
With OLEDB we need the SQLOledb Provider installed on each client and we have a connection string (with encrypted user/pwd) in an ini-file, which is used by the client.

In our and your case, the applicaton and it's ini-files resides on a directory on the server which is shared and mapped on the client.
This means, that the application is in fact installed on the client, not on the server.

If it would be allowed to install the Microsoft OLEDB Provider on each client, you could think about migrating to OLEDB.

If not and if you want to run the application on the server, you have to change your architecture.
You and we have a 2 tier application. 1 tier is the client, the 2nd tier is the database server.
You and we would need a 3 tier application. 1 tier is the client, the 2nd tier is the business logic running on the server and the 3rd tier is the database server.
The best way would be to change the application to a web client and a business logic on the server running as web services.
We thought about this in migrating our application to C# and to a web application.
But we skipped this project and migrated to TD 7.4 instead...

If anyone knows an easier way, we would be interested, too.

Regards,
Rainer

[karthik]

Thanks for your feedback. We are looking for a quick solution as migrating all the TD applications will take more and it can be longer term solution.

[Steve Leighton]

.
I don't know about ODBC, or how long you have to get this right, so best advice is run OLEdB instead of ODBC.
Its faster and the latest OLEdB driver has a lot of functionality.
Its being developed by MS a lot more than old ODBC.
You don't need any sql.ini at all, anywhere, and the .udl file containing the connection string can sit on the server, and read into the SqlUDL variable in the client app.
You don't need SqlUser, SqlPassword or SqlDatabase.

If you cant use OLEdB, then you can try and find every gupta.ini and delete it.
TD copies configuration data from ODBC to gupta.ini and uses this information firsthand.
So the contents of gupta.ini on the client may be out-of-date.
If you change ODBC-settings on the server they will not get to your TD-application.
It's always safe to delete gupta.ini files. They just get re-created again. Worth a try.

[karthik]

Hi Steve,
Thanks for your suggestion.
Is it possible for us to schedule a meeting with you so that we can explain our problem and to evaluate the OLEDB suggestion provided by you work for us.

Thanks and Regards
karthik

[Steve Leighton]

.
Karthik
Sure , no problem . Be happy to help.
PM me here: https://www.banksidesystems.com/contact-us
or
support@banksidesystems.co.uk

with your details, and we'll make the arrangements.

[RainerE]

Note that moving to OLEDB needs some changes depending on your code and your SQL statements.
We have successfully moved from Native SQLBase connectivity to Microsoft SQL Server OLEDB with our large application.

There is a built in OLEDB-Provider within Windows. But this version is not secure any more and connections should be rejected by SQL Server in the meantime.
You have to install a new(er) version of the Micorosoft OLEDB-Provider, which is available for free, on each client where your application is running!

You can use the new varianble sqlUDL, which works fine for us.
You can then still use SqlConnect() and SqlDisconnect().

Don't know, if you already did this because I don't know how ODBC handles lost updates:
If you were using the old 'where rowid=:sRowid' part to avoid lost updates by getting an error, this will not work any more.
You have to call SqlGetModifiedRows() after each update or delete and check, if the expected numer of rows has been updated.
You can implement this in a way, that the old InvalidRowId-Error is triggered, but you have to include the check after each update/delete statement.

Don't know if this is relevant for you:
And note, that TD will not run stable, if you are connecting against 2 or more SQL Server databases at the same time.
The first connect can be done the way described. For all further connections you have to use the old methods SqlCreateSession() and SqlCreateStatement() instead.

Don't know, if you already did this because I don't know how ODBC handles commits:
And we had to change the way of calling rollback/commit, too.
SQL Server thows an error if you do a commit/rollback without starting a session.
With SQLBase you can call commit/rollback as often as you want.

Kind regards,
Rainer

[karthik]

Hi Steve and Rainer,

Sorry for the late reply and thanks for your valuable feedback.
We are working with Open Text support for the solution and based on their suggestion trying OLEDB to connect to applications running on the server from client machine.
Will reach out to you if we need any support.

Thanks and Regards
karthik

[RainerE]

Ok, good luck!