ISEMPTY and permissions

einsTeIn.NET

Hi guys,

Do I need permission to the table when I execute ISEMPTY?

We encountered a very strange system behaviour. It's a 5.01 Object base running on 6R2 system. We never used RTC in this database. That's why table Profile was empty all the time (will only be filled when at least one of the standard role center pages is available). We never had an issue with LogInStart in CU1 where it checks if the Profile table is empty.

Now, we enabled some RTC functionality for some users. That's why we imported the pages. Of course, the first user that logged in (SUPER user), created the standard records in the Profile table. But afterwards all other users receive an error message regarding permission to Profile table when it checks if the Profile table is empty in CU1.

Does ISEMPTY only require permissions to the table when it's not empty? Is there any reason for this behaviour?

ara3n

If the table has data in it, NAV will check and see if you have permission to that table. Now permission are done for two reasons.
One is your license and second the user permission. In both cases, if there is data in the table and your code tries to execute any command against the db, NAV will check the permission. If you don't have permission either based on roles assigned or based on your license, nav will error out that you don't have permission.
This happens a lot when a person is using developer license and inserts a record into a table that the user license doesn't have and you get the error. In your case it's not a licensing issue but a security role issue.

einsTeIn.NET

I know all that stuff regarding license and permissions. My question was more about why ISEMPTY behaves different depending on whether the table is completely empty or not.

What I remember from the past is that ISEMPTY is faster than any FIND/COUNT statement because it doesn't execute any read operation in the database. If that's the case then I wonder why it behaves different if the table contains records or not.

ara3n

Yes it does issue a sql statement. The difference is

SELECT * FROM table for find/findset

where as in isempty it's

SELECT TOP 1 NULL

einsTeIn.NET

Does that mean it's an SQL issue? So, SELECT TOP 1 NULL from table xyz behaves different depending on whether the table is completely empty or not? What if I apply a filter beforehand?

From my point of view that's a bug because it could lead to error messages just because a user enters data into a table.

einsTeIn.NET

Just tested it in native classic client... same behaviour. I think it's not just an SQL issue. If there are records in the table and you apply a filter then you always get the permission error. That means if the result is empty because of applied filters then it also checks for permissions to that table. Only if the table is completely empty then it doesn't check permissions. :-k :bug:

ara3n

its not a bug. it's been working like this.

einsTeIn.NET

Just because something is working in a certain way, that's no explanation for not being a bug.

I could think of why it works in exactly this way as for table Profile in CU1. Because no one should be affected by that table since RTC is in use. But as long as table Profile is only used for RTC it could be solved by ISSERVICETIER. But if you think of other situations, it's possible that one user stops all other users from working just because he enters data into a certain table. Then you have to apply new permissions to all users and possibly synchronise the user rights (worst case enhanced security model). That might take some time and users can't go on. At the moment I don't see any reason why NAV should work in this way. So, that's a bug or at least bad system behaviour.

bbrown

A bug is when something does not work as intended. While you may have a disagreement with the design, that does not make it a bug.

einsTeIn.NET

Well, referring to your signature, then it's an undocumented feature.

Seriously, in my opinion a bug could be everything that hasn't got a clear intention and possibly leads to error messages and/or wrong data. Since I haven't heard a good explanation (to be honest I haven't heard any) why it's intended to work like this, for me it's still a bug. I mean the designer of that function should have had an idea how it should work and why. This idea maybe doesn't cover all situations that could come up. That's quite normal in software development. But when someone faces such situation then the software producer should at least think about if the original idea misses something.

I don't feel pretty comfortable in shrugging something off as "by design" instead of asking for the reasons behind that design, just because it works in that way for long time.