When I removed my app from the Bluemix dashboard, it removed the associated SQL db as well. I have a script that creates new tables/indexes with our schema name but the free version of SQL database does not support user-defined schema names. The problem is in our code, we need to have our schema name rather than user*** schema name.
Does Bluemix still offer small version of SQL database ? If not, is there a way to recover our database, or is there a way I can rename the user*** schema created by the free version to the name I want?
Unfortunately it is not possible to use a user defined schema name. Anyway as a general rule in development, properties like schema name or connection properties should be parametric, in order to have more flexibility in your solution.
What is preventing to have your SQL to be adapted to the new db instance? You could have a simple script which load it and run on the instance, without any need to use an hardcoded schema name
Related
I am a newby in terraform and working with GCP project.
I have following terraform code that creates a postgres database for an existing database instance
resource "google_sql_database" "db" {
name = "test_db1"
instance = "already_existing_instance"
project = var.project_id
}
And I would like to understand how (if possible) to run some SQL initial script for that newly created database with terraform script. SQL script should create a table and insert few records.
Terraform is not really designed for schema management, so in the long run you might be better to seek out a tool more specialized for that task (for example, so that it can potentially modify the schema later as your needs change).
If you do still want to take these actions with Terraform, you'd need to seek out a provider which supports the protocol for whichever database engine you've selected. For example, if you're using the Postgres database engine then you could potentially use the cyrilgdn/postgresql provider. (I've not used this provider myself, so I'm just giving this as an example and I can't vouch for it's suitability.)
However, providers like these typically go only as far as creating the object which contains tables (in Postgres terms, the "schema" object). To go more granular than that, creating tables and possibly data, you may not be able to achieve your goals with Terraform alone (unless you write your own provider), and may need to resort to using external software for that final setup step.
I'm trying to create a link between MS Access and a remote Informix db.
The Access db will be used for generating reports/views etc with the data from the linked Informix db.
I have setup a DSN for the Informix DB and can connect to it.
Using the MS Access 2016 GUI I can select to create a link via the external data tab. However, I need to make sure that this is a read only link. It is imperative that any changes made (either on purpose or accident) in the linked access db do not filter back.
One option I have considered was contacting the Informix DBA to make sure my account is read only. Unfortunately, this is not possible, so I wonder if there is some other approach I can take?
Informix ODBC doesn't support SQL_ACCESS_MODE and as far as I know, there is no option that would make a 'read-only' connection.
You can ask our DBA to create a view on the table and restrict access on just that view (e.g. only have the 'SELECT' permission on it). Then use that view as the source for your linked table.
A second option would be to not have a linked table, just import the data from the source.
There are several things you can do to create a read-only connection.
The most secure way, in general, is to create a user that only has read access, and use that user for your DSN (also fixes the issue that DSN information is publicly available in Access and might be reused.
Another way is to set SQL_ACCESS_MODE to 1 (=SQL_MODE_READ_ONLY) in your DSN file, which creates a read-only connection on supported databases. However, a tech-savvy user can just change that value, so this doesn't add the security the first way provides.
Best safest solution is for the Informix DBA to create a new user for your Access front end with GRANT SELECT permissions only for the tables your application will be querying.
I just came across the concept of SYNONYM in a database. By reading this: http://msdn.microsoft.com/en-us/library/ms187552.aspx
and this What is the use of SYNONYM in SQL Server 2008? I figure out the purposse of synonym.
however, I still don't understand a little step in real process of creating a synonym for a remote table. I have search the web, but generally the instruction mainly focus on SQL syntax(for example this one:http://www.oninit.com/manual/informix/english/docs/dbdk/is40/sqls/02cr_prc8.html). And I find none of the guidance mention the authentication part when creating a synonym for remote table. I guess a database can't just let anyone make a synonym then get the access to its tables?
so I curious how the target remote table's database can know if the synonym reference accessing its table is legal?
The answer to your question is going to depend a lot on what database platform you are using to contain the synonym; in your question, you referenced documentation from at least two (SQL Server and Informix). I don't know much about Informix, but I'm going to assume that it's security model is different than SQL Server.
For SQL Server, the remote server must be set up as a linked server first (assuming that you are using a remote object). See http://technet.microsoft.com/en-us/library/ms188279.aspx for details on how to do that.
From CREATE SYNONYM:
You do not need permission on the base object to successfully compile the CREATE SYNONYM statement, because all permission checking on the base object is deferred until run time.
That is, there's no security issues around synonyms, because the permissions checks take place when the synonym is used, and the permission checks are based on the real object, not the synonym.
I am wanting to duplicate an existing schema with the table structure, but not any of the existing data. Essentially, we are separating two companies that currently share a single schema in the database, and they have the exact same data structure, but we want them in different schemas (for access control purposes).
It is possible to copy the entire table structure of one schema into a new schema without bringing over any of the data?
You can do that in SSMS (Sql Server Management Studio)
Right-click on the database
Script Database as
Create to
File
Do a global search-and-replace in the resulting file, changing your schema name to their desired schema name.
I suggest going forward that you maintain change scripts to apply any needed changes to the DB as the application is further developed. That way, you can just share the change scripts and each apply them when you are ready to upgrade the app version.
Why does SQL Server create schemas for the initial DB roles, such as db_accessadmin, db_datareader, etc.? I understand the roles and why they exist, but I don't understand why they are given schemas when the database is created. Does anybody use them? I can't imagine that Microsoft recommends adding tables to them. I can't see adding an employee or product table to db_datawriter. Are there some kind of hidden system objects owned by them?
Others have said legacy/backwards compatibility without really explaining it.
When SQL Server 2005 was introduced, they introduced user/schema separation. Before that time, each user and role implicitly had a schema of the same name associated with it (and there was no way to create schemas, other than by creating users or roles).
So, for those built in roles that existed in the 2000 (or earlier) versions of SQL Server, there was always a schema "available" in the database with the same name as that role. So some code may have been written assuming that such schemas existed; later versions of SQL Server ensure this is still true, to avoid breaking such code.
Legacy.
You should use explicit GRANT (say GRANT ALTER USER TO ...) rather then using the legacy fixed database roles.
If you use sp_grantdbaccess you also get a schema created: you should be using CREATE USER