I have this problem:
PostGis Server with a table: Table_Points_of_all_works
table has a field "ID_WORK" so I can filter points for only one work.
with different groups (a group for each work).
Each group can access to the only work related, and view, insert, delete rows (related to their only ID_Work)
To do this I created groups and policies:
CREATE POLICY policy_for_this_groupofWork
ON public."Table_Points_of_all_works"
AS PERMISSIVE
FOR ALL
TO "GroupWork12"
USING ("ID_WORK"=12)
WITH CHECK ("ID_WORK"=12);
Viewing the table of points in QGIS works: only points of related work are seen.
But when I insert new points and giving in the field ID_WORK correct work (12 in this case), I receive an error while updating SQL:
"Could not commit changes to layer Table_Points_of_all_works
Errors: ERROR: 1 feature(s) not added - provider doesn't support adding features."
If I do the same thing with admin users (postgres) all works fine.
Anyone can help me?
thanks in advance,
Filippo
Related
Good day,
I run many databases under interbase XE7 and 2017 now.
Lately, I got a strange behavior on one of the db:
A table with a primary key was found hosting many rows with similar values, like image below.
We can see that SCRIPTTYPE is a primary key column and it contains many times MATRIX, no space or strange characters ( I checked).
I was able to backup / restore without issues.
I am puzzled by this and I am wondering if anybody did encountered something similar?
And how it was done?
Thanks.
enter image description here
Run this query to be sure:
select SCRIPTTYPE, count(*)
from yourtable
group by SCRIPTTYPE
order by 2 desc
If you get a count>1, then I'd argue it's simple a bug and you should contact support. For them to assist you they'll almost certainly need your database, so you should be prepared to provide that. Based on your description, you should be able to drop all tables except the one, and drop all fields except your key, then backup and restore to get the simplest test case.
I'm trying to setup some custom monitoring for postgres and one of the metrics I want to see is the index usage from pg_stat_user_indexes. I have multiple databases, each of them have indexes and I want a single metrics role that has access to all of them.
The problem is that when I select * from pg_stat_user_indexes using the metrics role I see no results. But if I select with the individual database role I see the stats just fine.
The metrics role is a superuser with Bypass RLS. I tried looking at pg_stat_all_indexes but I can see only pg_* stuff.
https://www.postgresql.org/docs/current/static/monitoring-stats.html#pg-stat-all-indexes-view
The pg_stat_all_indexes view will contain one row for each index in
the current database, showing statistics about accesses to that
specific index. The pg_stat_user_indexes and pg_stat_sys_indexes views
contain the same information, but filtered to only show user and
system indexes respectively.
emphasis mine
Seems like you need to be connected to the specific database you want to monitor (not to postgres db) in order to see those stats.
Bizarre.. would have at least expected to see them all in pg_stat_all_indexes - it should have been named pg_stat_all_indexes_for_current_database_plus_pg_catalog - I know.. but pg_stat_all_indexes is not all indexes at all..
I am following the standard steps to create date dimension in SSAS here-
The generate schema option fails! this is the message from schema generation wizard
create failed for table myusername.dimdate
I think the problem is that the table should be created for a different schema. If below is the selected option for schema generation -
Subject Area
Data source view: ABC PROJ
**Schema: ABC_PROJ(WXY1230)**
Data will be preserved
Time table will be populated
Shouldn't the Dimdate table be created ABC_PROF(WXY1230).Dimdate and not under myusername.DimDate?
Any idea what could be missing? I have been struggling with this for hours now.
Thanks for any help.
I think that is an unfortunate bug in the SSAS generated date dimension. When you generate the dimension you are using your Windows credentials and SSAS uses the default schema for the user context it was provided. I believe your user has a default schema of myusername on that database, which is what is causing the date dimesion to be created there.
If you create the dimension, you have the option to generate the schema now or generate it later. If you choose to generate it later and go through the Schema Generation Wizard, you eventually see a screen that shows the Owning Schema.
. There is no mechanism to change it even though you can see it (At least not in SSDT. I don't have BIDS on any of my machines). You are not the only person to run into this issue.
So you have a few options as a workaround:
Use a different account that has a default schema that is the correct schema where you want to place your date table.
Create the table under your default user and populate it. Then alter the table in SQL Server to move it to the correct schema. Then update your DSV.
Don't use SSAS to generate your date dimension. There are plenty of scripts out there that create great date dimensions. Here's an example. This means you will need to create the dimension and build the hierarchy yourself, but it's not that much work compared to the time you've spent trying to fix this issue.
I have a Crystal Report with a database command:
The command has a join clause that can be removed and read from a table in the database, because it represents static data. I add this table (called _System) to the database expert:
Now I edit the command to remove the join and columns that reference this table. Since the report fields that depended on these columns are no longer mapped, this causes the Map Fields window to appear:
...which does not have the new table in it. If I cancel out of this I am back to where I originally was. If I hit OK without mapping, all of the unmapped fields on the report are deleted (suffice it to say... I was not expecting this >:( )
I have tried adding links between the command and the new table, and refreshing report parameters, but these have had no effect.
One workaround is to manually replace every field in the report, but this is very labour intensive.
Here is the outline of the command before:
SELECT ACT.Account_Code, ACT.Company, ACT.FName, --etc
STM.CompanyName AS 'DLRName', STM.Address_1 AS 'DLRAddress', STM.City AS 'DlrCity' --etc
FROM Accounts AS ACT
JOIN _System AS STM ON 1 = 1
GROUP BY ACT.Account_Code, ACT.Company, ACT.FName, --etc
STM.CompanyName, STM.Address_1, STM.City --etc
And after:
SELECT ACT.Account_Code, ACT.Company, ACT.FName, --etc
FROM Accounts AS ACT
GROUP BY ACT.Account_Code, ACT.Company, ACT.FName --etc
I have removed the JOIN on the _System table, and all referenced columns.
It appears to not be recognizing your _system table as a new source.
I would :
1) leave your command object SQL unchanged & get the issue worked out with the _System table, then
2) ensure that you are able to establish a join between the command object fields and the _System table fields, and lastly
3) then remap the fields.
Step two I suspect is the source of the problem, as your join condition is "ON 1 = 1" which I assume to mean that you may not have a common key field in both tables.
Note that your original command SQL selects STM.Companyname AS 'DLRName'.
Hence, crystal now know of a field called DLRName, but does not know of a field called CompanyName, hence it cannot make the association between DLRName in the old source, and CompanyName in the new source...
Likewise with the rest of the fields that are being moved from the command object to an attached table. if no name match exists...Crystal cant make the connection. However...it would list all unmatched fields that are on the report, and all unused fields in the recognized data sources, and allow you to specify the matches yourself.
But it does not...which tells me that something has gone wrong with the attempt to attach/open the _System table. Hence..you need to get that worked out first, then make the field adjustments.
If this doesnt get you thru...then show some sample data so I can see how the two tables are relating ( ensure some examples exists where there is a row match from both tables ).
I had the same problem a while ago.
Unfortunately I can't find anything online that helps, or maybe wasn't looking hard enough. I just noticed that in my case, that particular field that isn't showing in the map field dialogue box has nvarchar(max) as its datatype (in view).
I tried to force the datatype with CAST(missingfieldname as nvarchar(20)) as missingfieldname (I did this in the view), and voila, it magically appears in the map field dialogue box.
It seems that field mapping dialogue box aren't showing fields with blob texts.
I know this question was asked 4 years ago. But hopefully, this comment could help future solution seekers regarding this absurd and weird problem. I just got lucky seeing what's unique about that particular missing field.
Can any one help me why this error occurs when i update using sqlDataadapter with join query
Dynamic SQL generation is not supported against multiple base tables.
You have a "join" in your main query for your dataset (The first one in the TableAdapter with a check by it). You can't automatically generate insert/update/delete logic for a TableAdapter when the main query has multiple tables referenced in the query via a join. The designer isn't smart enough to figure out which table you want to send updates to in that case, that is why you get the error message.
Solution. Ensure that your main query only references the table you want the designer to write insert/update/delete code for. Your secondary queries may reference as many tables as you want.
It was in the case that i was trying to set value for identity column in my datarow. Simply i deleted the code to set value for identity column and it will work.
My Scenario:
Database:
uin [primary, identity]
name
address
Whenever i tried to set the datarow("uin") the error occurs. But works fine with datarow("name") and datarow("address").
Hope it works for you too