I'm a new sql user (3 days) and I'm having some problems querying data from database tables I've created, whereas there is no problems querying the default 'postgres' database tables. My first thought was that it was a access/privilege problem, but had no effect. I did also notice that my database activity in the dashboard is always idle, whereas the default postgres database is always active. So it looks like my database is available but not connected. Can I choose which database to connect to? Ive been checking the docs, but can't find how to make my database active. Any help appreciated. Thanks
When you connect to PgAdmin to a Postgres instance you get to choose which database you want your queries to work against. You can see an example here.
If you cannot see your database once you connect to the instance you might either:
1) not have the db created in that instance.
2) not have permissions to view/access it. For this one you may need to ask to the administrator of the db for the relevant permission grants.
Related
I would like to know does database is erased on daily basis which is created PHPMyadmin
Yesterday I have created a database by clicking "new" option under the Server "phpmyadmin demo-MYSQL(root)".Today that database doesn't exist.Any suggestions please and let me know whether I have missed nay steps before creating a database
You were using a demo.phpmyadmin.net server which is not intended for production and which removes databases created by testers on a daily basis.
I'm new to Postgres, not to SQL. I generally use Navicat to connect to my databases, so I've set up a connection to a remote Postgres DB the same way I normally would. I'm able to:
Connect successfully
List databases
When I click on the database with my tables, however, it expands the database but doesn't show anything. No tables.
I saw the other question here, where a user was trying to get into 'template0' and 'template1': Some PostgreSQL databases not visible through clients like Navicat or pgAdmin
I'm not trying to get into these, but into a custom DB full of tables. I've verified that both my web app, and phpPgAdmin can both access all the tables and data, so the issue seems to lie with Navicat.
I read some instructions about how these tables might be 'system items', and went into the Navicat preferences and checked the box that says 'Show system items (PostgreSQL, SQL Server)' to no avail.
One thing I also tried, as I'm using Navicat Premium, is to install the Navicat PostgreSQL version instead. This also yields exactly the same results, I can see my database but none of the tables.
What's going on here?
EDIT
With some great help from Vao Tsun, we determined that this is PostgreSQL 7.2.4 and that it is not supported by Navicat.
https://www.navicat.com/products/navicat-for-postgresql:
Navicat for PostgreSQL connects you to any local/remote PostgreSQL
database servers from version 7.3 or above.
It does not work with PostgreSQL 7.2.4
My Background is MySQL/PhpMyAdmin and there I can create easily new database by entering the name in Phpmyadmin, But I'm facing problem to creating database in Oracle SQL Developer... I already connected HR_ORACLE default database and test the connection. But I don't know how to create new database?
You usually only have one database (=instance) in Oracle. A database in Oracle is something completely different than a database in MySQL. Actually MySQL calls databases "schemas" and that's what they are best mapped to in Oracle.
To create a new schema in Oracle, you create a new user. Those two things are more or less the same (there are some subtle differences, but as you are a beginner just assume that it's the same for now).
To create a new user, you need to connect as a privileged user (typically SYSTEM or SYS) and run the CREATE USER command.
I don't use SQL Developer but I think it has some DBA tools built-in that can probably help you with that. Just seach for "user management" or something similar. You do not want to create a new database if you have Oracle up and running.
Further reading:
2 Day DBA - Administering User Accounts and Security
SQL Developer's User Guide - Create/Edit User
Database Administrator's Guide - Managing Users and Securing the Database
Concepts Guide - Oracle Instance Architecture
Edit (as you seem to be confused about the new user):
Each user can (by default) only access the tables that were created under that user (the ones that user owns). So if you create a second user NEWBIE and log in with that user, you won't be able to access the tables of the user (schema) HR_ORACLE. If you create a new table as NEWBIE that table is created in the schema NEWBIE and is owned by the user NEWBIE. The user HR_ORACLE can not access the tables owned by NEWBIE (unless given the necessary grants)
I have a few databases that I want to migrate to another server. These are production Databases, what is the best way to Migrate
1) Take full back up of the Current Databse and then Restore it on to the other Server.
or
2) Detach and then Copy the mdf/ldf files on the Destination Server and then attach the files there.
I know that after Migrating Sql Logins and Sql Agent Jobs will have to be created manually. Are there any other risks that come to mind?
Any help will be helpful.
Thanks,
Ben
For Login transfer use "sp_help_revlogin" you get the script
https://support.microsoft.com/en-us/kb/918992
this Stored procedure list out all the instance login not particular database login. One special thing about this stored procedure is no need to do orphaned fix. Just migrate the logins and check. It works.
What's a good way to manage and maintain SQL Server logins, server roles, and individual access rights across multiple databases that exist in multiple environments? What are your best practices?
Some info about my situation:
SQL Server 2005
We have N amount of "client" databases with identical schemas (in theory, at least)
We have a central "admin" database that references each client database and can hold configuration values
This "admin/client" pattern is duplicated across multiple environments (dev/qa/stage/prod)
Some users, like testers, need different rights based on evironment
We frequently have to pull client db backups from one environment to restore on another for development or testing purposes
We keep our stored procedures and scripts in source control and deploy in a build cycle
Right now my organization is chaotic and we don't follow good security practices. We have no formal DBA. However, if we got any more complex it would be a constant hassle to maintain it all the time. I could see migrating to a new server or recovering from disaster being extremely time consuming if we where to attempt configuring it directly through the management studio IDE.
First, to make restoring a database to a different server easier, make sure that your logins all have the same SID on all of your servers by using the sp_help_revlogin stored procedure from Microsoft to script the login on the first server you create it on and then use the script to create the login on your other servers. This keeps the database user mapped to the login correctly when you restore the database.
Having different permissions at the database level depending on the environment is going to be a hassle to a point no matter how you role this out. I have a stored procedure in master that gets called on my Dev Server as a part of my restore process that performs the additional GRANT's on the database to give the developers access to make changes. That's the best I have been able to come up with to solve similar problems.
A way to make the rights easier would be to create rolls in the database called Dev, QA, Test, Prod and grant the correct rights to those roles. Then as you restore the databases to each environment just drop the developers in the correct role.
We use active directory groups and enforce windows authenticated logins. From within SQL Server we can then define access based on the AD group the user is in by creating a single SQL Server login per AD group. Not sure if this is any better or worse than DB roles, but it means the roles are managed outside each database.
Propagating access to databases is then either a manual operation or a short SQL script to ensure the logins in the database point to a valid SQL Server login (which in turn is an AD group).
Generally this works well for the general case. We can use DB roles then to assign the builtin roles (e.g, db_datareader) to each AD group
Rarely someone needs some specific access to a database outside this model. We either end up opening it up to the group as a whole if it's not going to be invasive or critical or we'll end up creating a per-user account that has to be managed separately. We endevour to keep these to an absolute minimum, and clean them up every now and then so they're not abused/forgotten about.