Connecting Ingres from C - ingres

I need to connect to an Ingres supplied demodb through OpenAPI, both Ingres and C application running on windows. What i have done:
Created a "node" in the Ingres Network Utility named "usernode".
created user accounts in the Ingres installation (named "user" password "user") and in the Windows user management (the same creds.)
Granted necessary privileges to the user in the database.
In C code i have called IIapi_connect() function with an IIAPI_CONNPARM structure.
Used members:
co_target = "usernode::demodb",
co_username = "user",
co_password = "user"
But IIapi_connect() call returns an error:
"User provided a vnode as part of the database name (vnode::dbname), but connection information for that vnode is missing. Enter connection information for the vnode using NETUTIL."
Anybody knows something that is a weird concept "node"?
What are the minimum steps (in the database administration and the function parameters passing) necessary for the successful connect?

You get the following error because your user id has not been added to the server.
"User provided a vnode as part of the
database name (vnode::dbname), but
connection information for that vnode
is missing. Enter connection
information for the vnode using
NETUTIL."
I am guessing that the user id being passed across is defined in the virtual node (aka vnode) definition and it's that user that needs to be added to the user list on the server. The following will add a user from the command line, change USERNAME to the username you wish to add:
For Windows:
echo "create user USERNAME\g" | sql iidbdb
For UNIX/Linux/OS X:
sql iidbdb <<EOSQL
create user USERNAME\g
\q
Alternatively you can use a dynamic vnode in your connection such that co_target specifies all the connection information (including user details):
#server,protocol,listen_address[user,password]::database
for example
#localhost,tcp_ip,II[ingres,secret]::iidbdb
If you want to see a working example of OpenAPI code for Ingres take a look at the Ingres PECL extension.

You must create an account WITH password in the OS.
You must create a node with SAME username and password as in the OS. Don't forget to assign the "Remote Node" parameter in the "Connection Information" block to "localhost" (!) for example. It is an REAL ADDRESS(!). "Listen Address" parameter converts to a port internally. Leave it "II".
In the VDBA you, probably, have created an "user" account WITHIN THE ADMIN NODE. So, that account SHOULDN'T have ANY PASSWORD(!). You can delete it by entering existing password checking box "Delete Old Password".
For an authorization, normally shold be used process' credentials.
So, leave only user::demodb parameter co_target = "usernode::demodb".
Any questions?

Related

Can't connect with Oracle sqldeveloper or sqlplus

Right now I've just installed Oracle on Windows, so far I've successfully logged in with sys and system users via sqlplus and the enterprise manager GUI and created a new user. Now, I'm able to log in with this new user through the enterprise manger web interface but when I try to log in with sqlplus or with sqldeveloepr I get the error "ERROR: ORA-01017: invalid username/password; logon denied".
I've re-entered the password several times making sure not to make mistakes but yet again, I can't login. I can only connect with this user via enterprise manager web gui.
Any ideas why this would happen? :(
Here is the user logged into web EM
Error in sqldeveloper. I get the same error in sqlplus console, what I find strange is that if I use either system or sys user, it does connect successfully. So is my newly created user missing a role or privilege?
In the case of sqldeveloper I've tried both "localhost" and "127.0.0.1" as host and I'm getting the same result.
Maybe you don't have enough privileges. Try this:
grant connect, create session to <user>;
Well.. it seems that it's working now, at least with sqldeveloper. Apparently I needed to use the Service Name and not the SID when trying to connect, at least that's what I tried based on the answer by "thatjeffsmith" here: ora-12505 error while connecting via SQL Developer
I suppose that granting connect and create session also helped.
Also on the service name I typed the container name? for the pluggable database which in my case is "poraclepredb" the container being "oraclepredb". Now I'm able to connect with sqldeveloper. Still not sure on how connect with sqlplus though, since I can't "tell" which SID/Service it's using. Any ideas on that?
UPDATE: I was finally able to log in with sqlplus using the syntax:
sqlplus <user>/<password>#<host>:<port>/<database>
in my case for "database" i typed the name of my pluggable database.
The same can be done when sqlplus asks for the username, typing:
<user>/<password>#<host>:<port>/<database>
the downside on this is that the password is visible whenever I log in.

Windows: how can I set my PostgreSQL user to the superuser?

I am trying to create a database using PostgreSQL 9.4. I type "psql" in the command prompt, and then it asks for a password. I provide the password I set during the installation, but it says the authentication failed. After checking online, I concluded that I need to be using the superuser, named "postgres", which is the system user whose password is the one I set during the installation.
I am now trying to set PostgreSQL to this superuser. I spent a lot of time surfing the internet for a solution but wasn't able to solve the problem. I tried postgres ALTER USER myuser WITH SUPERUSER (I wrote that in the Windows command prompt), but it said that "alter" isn't recognized. Now, when I try to use PostgreSQL, my main problem is that I get the error: "role MYUSERNAME does not exist". (this is after I edited pg_hba.conf to make it not ask for a password)
By default, psql uses the name of the operating system to log in, to a database of the same name. If you want to log in as user postgres you should do:
psql -u postgres <any other options>
If a password is asked for, you give the password of the postgres user. You are now connected to the postgres database, where you really shouldn't be doing anything, except create new users (which are global to the installation) and other databases.
Once in the console, you can create new users like:
CREATE ROLE myusername LOGIN PASSWORD secret;
And new databases like:
CREATE DATABASE myowndb;
ALTER DATABASE myowndb OWNER TO myusername;
Then you log out from the console with \q.
In order to be able to access PostgreSQL using the new database, you have to edit the pg_hba.conf file (sample, modify to match your network settings):
host myowndb myusername 192.168.0.0/16 md5
Now you restart the PostgreSQL server from the Services tab in Administrative tools on the Control Panel.
Then you can log in to your new database:
psql -u myusername -d myowndb
Or use other clients like pgAdminIII.

Sqlplus login without password

I installed Oracle 11gR2 on my linux server. When I want to login via sys user on my db, I enter "sys as sysdba" and when system give password , I push enter and I can login on my db with sqlplus.
But, when I try to connect on Windows with PL-SQL tool, system wants to password. If I didn't write password (I defined password, password is "sys"), I cannot login on my db.
Why?
When you install oracle, it creates OSDBA and OSOPER groups. Any members of this groups will have OS authentication and can logon without a password.
When you connect from another machine, it's a remote connection and you must enter the password.
More info in the documentation.
When you connect on the same server you're being authenticated by the operating system; you can give any password you like, or it's more common to use / as sysdba.
When you connect from PL/SQL it'a a remote connection; operating system authentication isn't possible, so you're using password authentication.
I had such a problem and even with Oracle 12c on my linux server and what i did was that each time I open a new terminal I first type
"export TWO_TASK="
(without the the quotations) followed by pressing
enter.
Next I could then go ahead to type sqlplus "/as sysdba" (now as it is with the quotations)
to connect and continue.

Trouble Connecting to sql server Login failed. “The login is from an untrusted domain and cannot be used with Windows authentication”

I am trying to host a SQL server database, but whenever I try to connect to it I get this error:
The login is from an untrusted domain and cannot be used with Windows
authentication
I am connecting through Matlab using the following command:
conn = database('Clinical_Data','DoyleLab07\Acc','','com.microsoft.sqlserver.jdbc.SQLServerDriver','jdbc:sqlserver://DOYLELAB07\SQLEXPRESS:54287;database=Clinical_Data;integratedSecurity=true;').
Connecting to the database using matlab worked fine as long as I was using matlab on the computer which I was using to host the server. However, when I use another computer and the same Matlab command I get the error I showed above.
When I look under control panel\system. I notice that no domain is listed on my host PC or the PC I am using to connect to the host, but both computers are in the same workgroup. Would I be able to fix my problem by creating a domain and adding the foreign PC and the host to that domain? If so, how can this be accomplished?
Any suggestions will be very much appreciated.
Thank you for reading my post.
In order to use Windows Authentication one of two things needs to be true:
You are executing from the same machine as the database server.
You have an Active Directory environment and the user the application is executing under (usually the logged in user) has rights to connect to that database.
If neither of those are true you have to do one of two things:
Establish a Windows Domain Controller, connect all of the relevant machines to that controller, then fix SQL server to use domain accounts; OR,
Change SQL server to use both Windows and SQL Server accounts.
By FAR the easiest way is to change SQL Server to use both Windows and SQL server accounts. Then you just need to create a sql server user on the DB server and change your connection string to do that.
Best case option 1 will take a full day of installation and configuration. Option 2 ought to take about 5 minutes.
Getting rid of Integrated Security=true worked for me.
If your SQL Server is on one domain controller and you are trying to connect to it from another domain controller then you will get this error when
IntegratedSecurity = true;
This will happen even if you include a valid SQL Server username and password in your connection string as they will automatically be over-written with your windows login and password. Integrated security means simply - use your windows credentials for login verification to SQL Server. So, if you are logged in to a different domain controller then it will fail. In the case where you are on two different domain controllers then you have no choice but to use
IntegratedSecurity = false;
Now, when Integrated security is false SQL Server will use the SQL Server login and password provided in your connection string. For this to work, the SQL Server instance has to have its authentication mode configured to mixed mode, being, SQL Server and Windows Authentication mode.
To verify or change this setting in SQL Server you can open the SQL Server Management Studio and right-click on your server name and then select Properties. On the pop-up that appears select Security and you will see where to alter this setting if you need to.
I've had this same issue when using DNS aliases and hosts files to connect to a machine using a different domain name.
Say you have a SQL server called sql1 on mydomain.com - which is an Active Directory domain - and you also have a DNS zone for mydomain.net, and - for consistency - you set up a DNS alias (CNAME) record for database.mydomain.net --> sql1.mydomain.com
You'll be able to connect to sql1.mydomain.com using Windows integrated security, but won't be able to connect to database.mydomain.net even though it's the same server because the domain name doesn't match your AD domain.
Why not use a SQL Server account and pass both the user name and password?
Here is the reason why.
In short, it looks like you have an authentication issue.
The problem with workgroups is there is no common Access Control List like Active Directory (AD). If you are using ODBC or JDBC, the wrong credentials are passed.
Even if you create a local windows account (LWA) on the machine (SE) that has SQL Express installed (SE\LWA), the credentials that will be passed from your client machine (CM) will be CM\LWA.
This error message can also occur if the account you are using to access the SQL server is locked out by the domain.
In my case the Aliases within SQL Native Client 11.0 Configuration were pointing to invalid server/IP. Once updated it worked correctly.
To check:
1. Start "SQL Server Configuration Manager"
2. Navigate to "SQL Native Client 11.0 Configuration" and then "Aliases"
3. Ensure "Alias Name" and "Server" match correctly for TCP/IP
Following worked for me to get access from another machine to SQL Server using Windows Authentication. This approach may be useful only in development/test environment. E.g. you need to update password manually once you change it on your working machine.
On machine with SQL Server go to Control Panel and add new Windows User with same username and password as is on your working machine. Then create SQL Server login for this user:
CREATE LOGIN [SQLSERVERHOST\myuser] FROM WINDOWS;
Now you can use this login for Windows Authentication.
If you receive error 'The login is from an untrusted domain', this may mean that you changed password on your working machine and now need to update password on SQL Server machine.
Following was working for me. hope this helps you
<add name="getconn" connectionString="Data Source=servername;Initial Catalog=DBName;Persist Security Info=True;User ID=sa;Password=***" />
As mentioned here, you might need to disable the loopback
Loopback check can be removed by adding a registry entry as follows:
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck” Set this value to 1
Just adding my suggestion for a resolution, I had a copy of a VM server for developing and testing, I created the database on that with 'sa' having ownership on the db.
I then restored the database onto the live VM server but I was getting the same error mentioned even though the data was still returning correctly. I looked up the 'sa' user mappings and could see it wasn't mapped to the database when I tried to apply the mapping I got a another error "Fix: Cannot use the special principal ‘sa’. Microsoft SQL Server, Error: 15405". so I ran this instead
ALTER AUTHORIZATION ON DATABASE::dbname TO sa
I rechecked the user mappings and it was now assigned to my db and it fixed a lot of access issues for me.
If you using windows authentication make sure that password of the user hasn't expired. An expired password can explain this error. This was the problem in my case.

ADD ODBC database via batch file with Username/password

I need to install an ODBC database on a few computers and was hopeing to do it all via a batch file. I can get it to install the database connection string like so.
ODBCCONF.exe CONFIGSYSDSN "SQL Server" "DSN=DSNNAME | Description=Descriptionname| SERVER=ServerName | Trusted_Connection=Yes | Database=dbname"
pause
#CLS
#Exit
But i need to add that it should log in with with an Login ID and password NOT with the network login ID.
Anyone know how i can fix this?
also its on 64 bit windows 7
Thanks
http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/53f689c1-53c8-45c6-b9ce-c44bce46cd9d/ says "Persistence of login credentials in a DSN is not supported (it's insecure). Using trusted connection would be the best way to achieve connecting without specifying credentials since the logged on user credentials is used for authenticating to the server."
If you change to Trusted_Connection=No it will add the DSN, but you'll then need to run the ODBC Data Source Admin and add the user and pwd to the new DSN by hand.
btw, according to http://msdn.microsoft.com/en-us/library/windows/desktop/ee388579%28v=vs.85%29.aspx "ODBCCONF.exe will be removed in a future version of Windows Data Access Components. Avoid using this feature, and plan to modify applications that currently use this feature."

Resources