How can I specify a schema name in SQL ConnectionString using ASP.net dynamically.
I have a single database with multiple schema. I need to fetch data from table belonging to particular schema.
You can only specify the database and user details in the connection string.
To retrieve data from a specific schema, you need to reference that schema in your query. For example;
SELECT field1, field2 FROM [Schema].[Table]
I would like to reference here an older thread, which is definitely useful in this question:
Possible to set default schema from connection string?
You can only set the default schema to the user itself.
You can try an ALTER USER statement, where you can define a default schema to the user.
It means you can create a user to each schema, if that is what you need.
Each user has their own schema and that is the default schema. Once logged in you can execute:
ALTER SESSION SET CURRENT_SCHEMA = myschema
So you need to execute an extra statement after connecting.
Related
I have an ASP.NET (C#) web application that connects to Informix 12.x database. The web application uses a database connection string with username and password. Users are given login accounts to use the web application and they can delete records in the database.
The database tables have "LastModifiedBy" which contains the user ID. Now, I need to implement auditing using database triggers. I need to capture what records were updated or deleted and who did it (i.e. logged in user) and save these in an audit table.
For the delete trigger, how can I capture the user ID of the logged in user and save this in the audit table?
The database user (available via the keyword USER) is always going to be the username associated with the shared database credentials. Your question is not very clear, but are you saying the existing LastModifiedBy attribute contains the named user or the database user? If it's the named user, I think you should probably look at your ASP.NET code to see how that gets passed into the UPDATE statement.
I'm no expert on ASP.NET, but assuming a single page request uses the same database connection throughout its processing cycle, then you could maintain a table keyed on the session ID, available via DBINFO('sessionid'), where you capture the named user at the top of the request, and then you have it available at any point throughout the process for inclusion in your audit. But if the web-server processes are using a pool of database connections and any statement could go to a different connection, even that won't work.
Ultimately, I don't think database triggers are the right solution here, not least because you'll have to write and maintain a trigger for every table in your application. If I was faced with this problem I would be more inclined to have a common Audit function within the web-app, where the named user is always available.
At the OP's request, a bit more detail. The Session ID is exactly the same concept as you see in SSMS - just a unique number that identifies the connection.
Imagine you have the following table and procedures:
CREATE TABLE session_user (
sessionid INTEGER NOT NULL,
username VARCHAR(20),
conn_date DATE,
PRIMARY KEY (sessionid)
);
CREATE PROCEDURE set_user(v_username VARCHAR(20))
UPDATE session_user SET username = v_username, conn_date = TODAY
WHERE sessionid = DBINFO('sessionid');
IF DBINFO('sqlca.sqlerrd2') = 0 THEN
INSERT INTO session_user VALUES (DBINFO('sessionid'), v_username, TODAY);
END PROCEDURE;
CREATE PROCEDURE get_user()
DEFINE v_username VARCHAR(20);
SELECT username INTO v_username
FROM session_user
WHERE sessionid = DBINFO('sessionid');
IF v_username IS NULL THEN
LET v_username = USER;
-- return system user if no record found in session_user table
END IF;
RETURN v_username;
END PROCEDURE;
NB: None of this code is tested, it's just to show the principle. I don't have an Informix instance to hand to test this on.
At the top of the request, however you execute your SQL, you would run:
EXECUTE PROCEDURE set_user($the_web_user);
Your triggers could then use get_user() wherever you want to capture that info. You'll get the actual web user if it's been recorded in the session_user table, otherwise the database user (which will be the shared database credentials if the triggering DML has come from the web-app, or the physically logged in user if the trigger is via a DB-Access session).
I still don't think this is a particularly maintainable solution - every table needs its own trigger(s). An OO audit method in the web-app would be a more DRY approach, or have a look at Informix's preexisting audit capabilities.
Note: the date field was included in the session_user table so you run a clean-up over it, because depending on how often new connections get created by the web-app, your session_user table could grow like topsy.
Is it possible to have a database name as case-sensitive?
For example, in flyway.conf
If I declare a schema as:
flyway.schemas=MySpecialDB
Datebase is then generated as myspecialdb but the desired name is MySpecialDB.
This is observed when using MySQL.
This sound's like your DB is configured to store table names in lower case. Checkout lower_case_table_names in the official MySQL docs for more information.
Do we have any way to specify default schema in cataloged DBs in db2 client in AIX.
The problem is , when it's connecting to DB, it's taking user ID as default schema and that's where it's failing.
We have too many scripts that are doing transactions to DB without specifying schema in their db2 sql statements. So it's not feasible to change scripts at all.
Also we can't create users to match schema.
You can try to type SET SCHEMA=<your schema> ; before executing your queries.
NOTE: Not sure if this work (I am without a DB2 database at the moment, but it seems that work) and depending on your DB2 version.
You can create a stored procedure that just changes the current schema and then set the SP as connect proc. You can test some conditions before make that schema change, for example if the stored procedure is executed from the AIX server directly with a given user.
You configure the database to use this SP each time a connection is established by modifying connect_proc
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.admin.config.doc/doc/r0057371.html
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0057372.html
You can create alias in the new user schema that points to the tables with the other schema. Refer these links :
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.sql.ref.doc/doc/r0000910.html
http://bytes.com/topic/db2/answers/181247-do-you-have-always-specify-schema-when-using-db2-clp
I am writing a web based importer to import data from one database to another database. Since the data gets loaded into a table that has an identity, I need to enable Identity_Inserts prior to executing my insert statement. I generate the SQL statements I would need to run into a List, and what I would like to do is set IDENTITY_INSERT to ON prior to looping through the commands, then set it to back off once complete. I am going to execute each command one at a time because I want to keep track of which commands failed.
I tried executing SET IDENTITY_INSERT [TABLE NAME] ON before starting the loop, but this isn't working.
How can I accomplish what I am trying to do, or does anyone have any other ideas?
Taken from https://connect.microsoft.com/SQLServer/feedback/details/517923/set-identity-insert-already-on-error-message-always-returns-dbo-schema-name
SQL 2k8 BOL states "At any time, only one table in a session can have the IDENTITY_INSERT property set to ON. If a table already has this property set to ON, and a SET IDENTITY_INSERT ON statement is issued for another table, SQL Server returns an error message that states SET IDENTITY_INSERT is already ON and reports the table it is set ON for."
So I guess, you'll need to set it OFF at the end of the loop?
Elevated permissions are required to execute SET IDENTITY_INSERT option, check if your user meets one of those:
User must own the object, or be a member of the sysadmin fixed server role, or the db_owner and db_ddladmin fixed database roles.
For some reasons,the schemas of database is not dbo. When using SqlWorkflowPersistenceService in WF,there would be an error found "cannnot find Stored procedure 'RetrieveNonblockingInstanceStateIds'".But if I update the procedure from "XXX.RetrieveNonblockingInstanceStateIds" to "dbo.RetrieveNonblockingInstanceStateIds"
there would be ok.How to fix it? Or how to define the default schemas in WF? I have set schemas XXX as the default schemas in current use login by asp.net in SQL 2005
I have solved it.
I create a user without sa permissions in SQL
The stored procedure can be found
It seems that if your accout contains sa, your default schemas cannot be personal even if you have set it.