New answers tagged

0

The password complexity is managed by a function. You can edit the function to fit your requirements or disable it at all. Check this link : https://docs.oracle.com/en/database/oracle/oracle-database/18/dbseg/configuring-authentication.html#GUID-A39E191B-4A06-442D-94C7-5882B73DDCFA On the section "Managing the Complexity of Passwords" For the password "...


2

This is standard SQL behaviour for pretty much all databases. There are three ways how rows are returned: without aggregate functions, the query returns one row per row; with aggregate functions, but without grouping, the query returns exactly one row; with aggregate functions and grouping, the query returns one row for each group (i.e., for each unique ...


0

This is expected behaviour (not only for Postgres). If we look at the logical order of evaluation for a query: FROM WHERE GROUP BY SELECT I'll add a table (T) with one column (x) and one row in the example We have: SELECT COUNT(1) as CNT FROM ( VALUES (1) ) AS t(x) WHERE false GROUP BY () -- empty set default The result is one row with value 0. Then ...


0

A) Those options can only be switch by logins with elevated permissions. Therefore to alter them at run-time the application must run with elevated permissions. This is a security risk. B) Actions performed in this way run in the DBMS's process. Any instability (bug, exception) they cause will affect the stability of SQL Server and all clients it is serving....


1

In PostgreSQL, it is a pretty common set up to have "local" type set to "trust" or "peer", but "host*" types set to "md5" or the new "scram-sha-256" method. You seem to want the existence of a password to disable "trust", that would disable this setup as the password can't exist in one socket access method and not the other. I'd be pretty annoyed to have ...


1

I'd strongly consider using PostgreSQL, as it supports Row Security (as well as Column Security), and is free and well made You should also consider using real database users, but you don't have to. For example, you could set the current user into a temp table upon sign-in, and reference that username in your RLS policy


0

This appears to be answered here: https://stackoverflow.com/questions/496632/is-it-possible-to-log-who-started-or-stopped-a-windows-service/496675 Moral of the story is event viewer/ system logs should show you


0

as per the comment by Dominique Boucher those number seems to be indication of time, as per the picture below they vary. "The duration spent..." I would assume that those number are the time spend (probably in milisecond) to do the initialization and the handshake (an not port number)...


1

By default, SQL uses port 1433 and 1434 (if you are using named instance or the DAC connection). You can validate which port is used using SQL Server Configuration Manager


4

What am I missing? The DOMAIN\user login should be able to run dbo.sp_HelloWorld with it's corresponding user in the MyDB context. The EXECUTE AS USER command is the reason for the error being returned. Execute as user documentation Specifies the context to be impersonated is a user in the current database. The scope of impersonation is restricted ...


Top 50 recent answers are included