タグ付けされた質問 「debugging」

私は次を使用して有効なアクセス許可を照会できることを知っていますsys.fn_my_permissions： USE myDatabase; SELECT * FROM fn_my_permissions('dbo.myTable', 'OBJECT') entity_name | subentity_name | permission_name ------------------------------------------------ dbo.myTable | | SELECT dbo.myTable | | UPDATE ... これにより、現在のユーザーがmyTabledatabaseでSELECT、INSERT、UPDATEなどの権限を持っているかどうかがわかりますmyDatabase。 ユーザーがこれらの権限を持っている理由を簡単に見つけることは可能ですか？たとえばfn_my_permissions_ex、追加のreason列を出力する関数が必要です。 USE myDatabase; SELECT * FROM fn_my_permissions_ex('dbo.myTable', 'OBJECT') entity_name | subentity_name | permission_name | reason ------------------------------------------------------------------------------------------------------------------------------------ dbo.myTable | | SELECT | granted to database role public …

14 sql-server  security  permissions  debugging 

MongoDBドキュメントの挿入が検証に失敗した理由を判断するにはどうすればよいですか？返されるのは、「ドキュメントの検証に失敗しました」というwriteErrorだけです。これはあまり役に立ちません。 （これは頻繁に発生します。特定の例について助けを求めるのではなく、これらを適切にデバッグする方法を理解したいと思います。）

13 mongodb  debugging  data-validation 

この質問に対する再帰的なCTEソリューションについて説明しながら： 各IDの最後の5つの異なる値を取得する @ypercubeは驚くべき例外に出くわし、型修飾子の処理を調査することになりました。私たちは驚くべき行動を見つけました。 1.型キャストは、一部のコンテキストで型修飾子を保持します しないように指示された場合でも。最も基本的な例： SELECT 'vc8'::varchar(8)::varchar 一つは、期待していないかもしれないvarchar私は、少なくとも、（無修正）でしょう。しかし、結果はvarchar(8)（修飾子付き）です。以下のフィドルで関連する多くのケース。 2.配列の連結により、一部のコンテキストで型修飾子が失われる 必要がないので、これは反対側でエラーになります： SELECT ARRAY['vc8']::varchar(8)[] , ARRAY['vc8']::varchar(8)[] || 'vc8'::varchar(8) 最初の式はvarchar(8)[]期待どおりに生成されます。 しかし、2番目は、連結した後、別のものvarchar(8)がvarchar[]修正されます（修飾子なし）。からの同様の動作、array_append()以下のフィドルの例。 このすべては、ほとんどの状況で重要ではありません。Postgresはデータを失わず、列に割り当てられると、値はとにかく正しい型に強制されます。ただし、反対方向にエラーを発生させると、驚くべき例外が発生します。 3.再帰的なCTEは、完全に一致するデータ型を要求します この単純化されたテーブルを考えると： CREATE TABLE a ( vc8 varchar(8) -- with modifier , vc varchar -- without ); INSERT INTO a VALUES ('a', 'a'), ('bb', 'bb'); このrCTEはvarchar列に対しては機能しvcますが、varchar(8)列に対しては失敗しますvc8。 WITH RECURSIVE cte AS ( …

11 postgresql  datatypes  cte  debugging  cast