r_nagu
22nd March 2002, 04:01
Hi All:
I'd been trying to fix this problem from past few days, but running of ideas. Hope I will get some help from you guys.

We have two BaaN servers, one for development and other one is production. I set up a database authorization by user on table tcmcs002 (currencies) with authorization level “no authorization” for a specific currency, which we did not, wanted to use anymore. The idea was that, this will block all other tables which has a currency field and referring back to the main table [tcmcs002], since the users don’t have any permission on the main table for certain currency, they want be able use it any where. After setting it up, I tested it and it worked fine. But, when I did the same setup on our production server, it worked only on the main table [tcmcs002] but not other tables, which were referring to this table. After little bit of research I found out the problem is with the portingset. We have two different versions of portingset on these two machines, development one being the higher version.

Now, is there a way I can fix this with out upgrading the portingset on production server? I understand that portingset is nothing but the binary files in directory $BSE/bin, but I am not sure, is there just one file which controls this type of authorization/permissions?

You feedback is greatly appreciated.

Thanks,
NS

Francesco
22nd March 2002, 22:26
This does not sound like a porting set issue. I would rather double check your user authorizations and see if there isn't anything overruling your first restriction. A common problem, specially in the later versions of Baan where authorizations are anything but transparent.

victor_cleto
23rd March 2002, 15:29
Francesco is right, these authorizations are defined at the Aplication level so there is nothing related to the portingset, your problem has to be elsewhere.

r_nagu
24th March 2002, 02:03
Originally posted by victor_cleto
Francesco is right, these authorizations are defined at the Aplication level so there is nothing related to the portingset, your problem has to be elsewhere.

Thanks guys for your feedback. But, I am pretty sure this problem is related to portingset beacuse when i downgraded the porting set on our developement server to the version which is on our production server i was able to produce the same error. And when i upgraded it back, the problem was not there anymore. I could do the same with the production server ( upgrade the proting set) but, i am a little hesistant beacuse of the experience we had in past (we experienced lot of problems when we upgraded the proting set on our production server last time and it took us a while to fix them)

Thanks,
NS

patvdv
24th March 2002, 12:01
I would not be surprised that this is actually a portingset issue. Have you checked this with BGS? You should always upgrade *all* your files in $BSE/bin when doing a portingset upgrade. Possibly this could be a defect in your database driver which is not correctly handling database access calls.