RE: Client - Server

From: Raul A. Jager W.

Recently I got a beatifull (Looking) visual basic program to
enter/maintain purchase orders using ODBC to the iSeries.

For this program to work I had to give the user *CHANGE access to the
"order_header" and "order_detail" tables.

Now I have to questions:

1- How can I keep this user from reading the tables from other programs
like exel?

2- How can I define "commitment control" to avoid "half trasactions"
when the program fails?

Welcome to the world of ODBC.

The short answer is that security is almost impossible now. The best you
can do is parse each ODBC request in an exit point and make sure the
statement is valid. Performance will suffer as you have to programmatically
parse each statement, but that's the way it works.

And even then, if the Excel spreadsheet executes the same statement your
program executes, it will be very difficult for your exit point to
differentiate between the two.

That's one of the reasons I really don't like ODBC. Maybe somebody who uses
it more often (Walden? Richard?) can help.

As to commitment control, that depends on the language. In the .NET
languages, it's actually pretty easy. You create a transaction using
connection.BeginTransaction and then after executing your SQL statements
against the transaction you then execute transaction.Commit.

Joe