During project execution, users always find that the content displayed in Webtop is insufficient and want to see more data. This will inevitably directly read table data from the background database, the problem arises: 1) How do common users except the administrator can read the data in these tables? 2)How to deal with custom tables and views?
1. Set the read permission for common users for system forms
Due to user permission restrictions, normal users can only access forms already registered in da. to access other forms, perform the following operations:
1. log in with the superuser of administrator in Da and execute registered in dql for form registration. If the registration is successful, the system will report an ID.
For example:
Code
Register Table DBO. "dmi_package_s"
("R_object_id" Char ( 16 ),
"R_workflow_id" Char ( 16 ),
"R_act_seqno" Int ,
"R_port_name" Char ( 16 ),
"R_package_name" Char ( 16 ),
"R_package_type" Char ( 40 ),
"I _package_order" Int ,
"I _package_oprtn" Char ( 64 ),
"I _acceptance_date" date,
"R_package_flag" Int ,
"I _is_replica" Int ,
"I _vstamp" Int )
Key ("R_object_id ");
2. Execute the access permission of the registry list in the background database.
Update Dm_registered_sp
Set Owner_table_permit = ' 15 ' ,
Group_table_permit = ' 15 ' ,
World_table_permit = ' 15 '
Where Object_name = ' Dmi_package_s ' ; -- The ID r_object_id = * ID * of the corresponding feedback can also be executed here *
Here we willDmi_package_sAll the read and write permissions are granted. Therefore, you can set this parameter to 15, which can be determined based on your actual needs. Note: 15 = '000000', that is, all read/insert/update/delete permissions are granted.
2. Custom forms and views
The processing of Custom forms and views is the same as the preceding steps. The difference is that you need to create the corresponding table structure first in the background database. :)