During Oracle 21c database creation with DBCA OS 1053(sreenshot below) "OracleService{SID}" occurs. Tried adjusting ServicesPipeTimeout registry but it seems to take no effect as timeout occurs instantly. What could be checked to gain more insight into this problem? Couldn't find anything regarding the error in dbca log.
I had to go for "set up software only" in oracle installer because of "INS-30014: Unable to check whether the location specified is on CFS". Some people reported that disabling network helps with this issue but I am working on a remote VM so it doesn't seem to be an option for me.
System: Windows Server 2016 Standard
Seems that too long DNS name was causing the issue(above 15 chars). After making it shorter, managed to perform installation and services work correctly.
I'm trying to use SSIS to load some data from Oracle database to MSSQL database.
I created the project and used the ADO.Net source and was able to create a connection to Oracle and run queries and view results.
However when I actually run the package I get the following error:
Error: 0xC0208449 at Data Flow Task, ADO NET Source 2: ADO NET Source has failed to acquire the connection {EECB236A-59EA-475E-AE82-52871D15952D} with the following error message: "Could not create a managed connection manager.".
It seems similar to the issue here
And I did find that I have two oracle clients version installed "11.1" and "12.2".
One is used by PL/SQL and the other by other entity framework project.
If this is the issue I just wanted a way to tell the SSIS to pick-up the correct one.
I tried adding Entry in machine.config for "oracle.manageddataaccess.client" section with the desired version.
I also tried using other types of data sources but couldn't even create a successful connection
I tried changing the Run64bitRuntime property in the project to False
Note: I don't have SSIS installed on my machine.
Eventually, I just had to remove the entries related to 11.1 in path variable then restarted my machine.
Also I switched to "dotConnectForOracle" for connection and now it seems to be working fine.
I'm expecting issues related to other applications that might still be using the 11.1 version, but that will be a problem for another day.
Always make sure to write the user (oracle schema) in uppercase and some special characters [in my case it was $] in the password needs escape character even if you're using the wizard not the cmd
I still don't understand the whole issue but I hope this helps someone some day.
I am trouble shooting an error in a package.
Update MYTABLE for MYCOLUMN (REF to task name):Error: Executing the query "..." failed with the following error: "Invalid column name 'MYCOLUMN'.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I have verified the table and column exists, the length of the field is way excessive than what it needs that is 14 where it is declared as varchar(250).
I have verified the script works on the server in SSMS outside of the context of the package.
I have verified the connection and database in the package is as I expect.
Is there away to verify on the server. I did try to look at the Connection Managers tab on the package configuration itself i.e. in the Integration Services Catalogs->SSISDB->solutionfolder->..->package.dtsx->Configure context menu but it is empty.
Any ideas on how to troubleshoot?
Just to add more context the package contains 27 other tasks, 9 tasks in a row linked to this task but all set to on completion, all seem to be doing stuff independent of the other. 1 task is a loop doing stuff and the rest are single independent tasks. So I don't know at this stage if it is a cascading connection issue perhaps however; I am just reading what the log says.
I kicked off the package at 9:54am, the timestamp on the error log says 11:45am so nearly 2 hours into running is this log reported.
I would suggest the below things to troubleshoot the issue.
I would suggest you to just have this task and disable all other
tasks to troubleshoot the issue. So that you can focus on this issue
specifically. That will tell you whether connection is working fine
without issues.
I would suggest you to edit the task and see whether parameters are
set properly. Different providers have different way of setting
parameters. Again check whether parameters are proper. Execute SQL
Task
one more thing, may be you are pointing the package to different
connection than the one you used for SSMS. So, it is working in SSMS
and in the connection being used in the package is not having schema
changes yet done.
I finally figure it out before I read the previous offered suggestion so will give some credit if I can! FYI: We have a lot of dev servers. I clicked on the overview hyperlink in the All Execution logs and it said another server. Also I found the connection on the job calling the package not the package itself so I have learnt something today. Anyhow the job said one server but the overview said another so I again I was back to square one scratching my head.
Then I decided to open the connection manager on the job and select the field and make no change rather then cancelling I clicked ok not thinking about it and noticed the field changed to bold face. So I am assuming if you make a manual change on the server in SSMS to anything it shows up in bold which is kind of useful. So I can only assume this is a MS SSMS or SSIS or VS deployment bug. That it does not overwrite, the previous connection although the SSMS interface says otherwise. Perhaps somebody can share some light. Having not checked the server before I made a change and deployed it I have no idea if the previous settings were changed manually by someone or the connection in the package was changed and deployed. Anyhow checking the job history shows it had been failing for awhile so it wasn't me so whoever and whenever a change was done by a previous developer didn't figure it our either or didn't bother or did not know how, or didn't observe it. Anyhow it is pointing to the correct server now!!!
i got this problem with postgreSQL, when i do a simple query of anything (CRUD), sometimes it works and almost always shows this message:
Not connected to the server or the connection to the server has been closed.
I don't know how to solve it and it started to irritate me, anyone know how to fix it?
UPDATE 1
I have been searching and it seems the pgadmin4 the problem (it seems because it's not 100% developed yet), i have been using pgadmin3 and that error doesn't show up.
solution is:
select the database where you lost the connection.
then on the right hand side select SQL
For example in the picture (shopdb) is the db where I lost the connection to.
After that PgAdmin will ask you if you would like to reconnect to this database...
click ok
you will notice a message retreiving data from the server
The reason this happened for me was a syntax error in the query. Check your syntax and try again, maybe this suffices
This issue has been fixed.
Upgrade to pgAdmin4 version 2.0. https://www.pgadmin.org/download/
I have similiar problem before, im using postgre 9.6.1-1
I can do select without condition (ex: select * from foodtable) and i can do insert too.. But if i do select or edit or delete using a condition (ex: select * from foodtable where taste='sweet') the output is like your
Not connected to the server or the connection to the server has been closed.
I try reinstall (After uninstall delete all leftover data) and delete C:\Users\yourUserName\AppData\Roaming\pgAdmin (delete all data inside pgAdmin Folder)
And its works
Update-> Your table name and field name must lowercase
Can you run & provide output of these sql queries from pgAdmin4?
1) SHOW SERVER_ENCODING;
2) SHOW CLIENT_ENCODING;
And what is the encoding set for your current database connection on which you are trying to run query (Right click on your database, click on Properties > Definition Tab > Check Encoding, Collation & Character type) ?
I'm suspecting you are facing issues due to encoding.
Change the versión of pgAdmin, use pgAdmin 3, its a problem frequently between Windows 10 and pgAdmin4.
just change the column name and run the query , it worked for me.
my column name was timestamp, it conflicted with datatype so i changed timestamp by _timestamp
Juuuuust in case someone googled this post like i did.
If you have JSON column AND you want to see ANY result in pgAdmin, cast JSON into VARCHAR like
SELECT id, metadata::VARCHAR FROM data_table;
It doesn't matter if content is NULL or not, JSON doesn't work. Maybe there are other types or values that can't be parsed by pgAdmin as well.
Note: you can still insert values and recieve them after cast, so the problem is on JS side (put one more coin into your "Hate JS" jar).
We have just experienced this on a standalone windows machine.
After reinstalling things and looking everywhere (logs, running psql in shell - all was good) then we found out that it was an older firefox that was the culprit.
So - please ensure that your browser is up to date :-)
I solved this. I pressed F7 or Explain in drop-down list near the Execute button. Then I saw where exactly the trouble was. pgAdmin4 didn`t like the name of my column. Then I went to problem column and renamed it.
I have same problem
but i can create DB and table successful
and my version is:
window10 pro x64
9.5 (X86)
pgAdmin4
after i change to 9.4 (X86)+ pgAdmin3 is no more error.. and the table i create by 9.5 can be use(insert data) in pgAdmin3
I am using the pgadmin version 4.6 which is the current release as for now.
I could only solve the problem by running query inside
DO $$ ... BEGIN ... END $$;
block.
In case anyone still looking for an answer like me.
I was getting this error when running a long series of queries in a transaction. Then when I ran them separately, it didn't loose the connection. Still no idea why it actually happens...
My operating system is windows 10.
pgAdmin Version - 4.5
I was getting this error when executing scripts, downgrading to pgAdmin version 4.3 fixed the issue for me.
I'm trying to open a password protected package in SQL Server BIDs and I keep getting the following error message each time I pu in the correct password:
Failed to remove package protection with error 0x80131940 "(null)"
This occurs in the CPaqckage::LoadFromXML method.
Any Ideas?
I ran into the same problem and discovered that caps-lock was on. Typing the correct password with caps-lock on gives the error message "Failed to remove package protection with error 0x80131940 "(null)", whereas typing the wrong password gives the "The password you have entered is incorrect" message. Very misleading but simple to fix.
I believe you thought you had the right password but that you really didn't.
I recently ran into this problem. I know you posted a long time ago but I could not find an answer when I ran into the same situation. Turns out I had the wrong password when I thought I had it right (I was not the one who created the package).
I had assumed that since some wrong passwords produced a wrong password error message that I must have had the right password with the one that did not produce a wrong password message - it turns out that different wrong passwords can return different error messages when opening a password encrypted SSIS package!
Very odd. At any rate, after finally getting a hold of the original developer, and getting the correct password, I was able to open the package just fine.
For what its worth I would never recommend encrypting the whole package with password, sensitive data maybe, but not the entire package.
I just received the same error. My issue was targeting SQL Server 2017 instead of SQL Server 2016 (Project > Propertied > Configuration Properties > General > Deployment Target Version > TargetServerVersion)
I got this message running a package built on vs 2017 enterprise on my laptop. In this situation people always fuss about your password. If you can get into the package with visual studio, you know your password. I was setting encryptAllWithPassword at the solution and package level. It was only failing with this message on my laptop as dtexec. When I moved the package to azure it ran with the /DECRYPT statement. So if you're only testing in one environment and it fails, try it in another environment (azure or server environment) and it might work.