I'm attempting to import an SQL dump in PgAdmin 4 using the psql client - However the error message returned is - The system cannnot find the file specified.
Here is a screenshot of my psql client -
The file films.sql is currently stored on my desktop, but I suspect the default location that the psql client accesses is not my desktop? Is there anyway to set the location that the client looks in order to resolve this?
The file SQL is viewable here: https://github.com/datacamp/courses-intro-to-sql/tree/master/datasets
I simply want to get the database on my local machine so that I don't need to store queries in an online learning platform. It would be best if this database is available locally to query and practice on.
I've attempted to execute the whole SQL file as a query on the films database but this does not seem to be working either and returns 'Asynchronous query execution/operation underway.
Query returned successfully in 388 msec.' - However it seems to be the case that the Asynchronous query never completes when I refresh the database.
Please can someone help?
Just give the path to your file:
psql -d my_database -f /path/to/the/file.sql
psql -d my_database -f C:/path/to/the/file.sql
Depending on whether you are on a unix/linux machine or Windows.
Oh, and if you aren't familiar with file paths you may want to take a step back and become more familiar with general computer terminology before diving into a RDBMS. Your learning will be much easier if you have a solid foundation to build upon.
I suspect this question might be moot for the asker at this point, but for anyone else stumbling upon it like I did: the interactive connection info prompts are provided by a batch script (in Windows, I'd guess there's an analogous shell script for Unix) called runpsql.bat, which then just passes your inputs as commandline arguments to the psql.exe executable. I was getting this error because I had migrated my Postgres installation and the batch script was calling a nonexistent path for psql.exe, hence The system cannot find the file specified. I edited runpsql.bat to point to the correct location of psql.exe and that resolved the issue. So for OP, I would look into PgAdmin4 and see where it's (presumably) calling runpsql.bat, then make sure that that calls psql.exe with the correct path.
Related
My database needs to mirror another, to which I have no access except for a nightly export of the sql file. I could script the import using psql.exe, but would prefer everything to be under the control of the dotnet core application.
I can't use the COPY command, because the file contains ALL the sql to set up the schemas and tables, as well as all the sql commands to insert/alter/copy the data.
I can't use \i because that is a postgresql console command, not something I can run through npgsql.
Is what I'm trying to do possible? Is it inherently a bad idea, and should I run a script to import it outside of the dotnet application? Should the dotnet application run and talk to the psql.exe program directly?
You could theoretically parse the SQL file in .NET and send it to PostgreSQL, but this is a very non-trivial thing to do, since you'd need to understand where statements end (identify semicolons) in order to send chunks.
You could, of course, send the entire file as a single chunk, but if it's huge, that may be a bad idea.
At the end of the day, I don't think there's any particular issue with launching psql.exe as an external process from .NET, and properly inspecting its exit code for error handling. Any reason you think you need to avoid that?
I've been having a bit of trouble trying to install PostgreSQL 14 for the first time.
I would like to apologize in advance if this question has been asked in the manner that I am about to ask it, but I do not think it has. If it has been, please direct me to the appropriate location!
I've done a fair amount of Googling on the matter, and all the information that I find seems to be rather fragmented, or I end up following a spaghetti trail of hyperlinks (a la-do-this-and-follow-this-other-link-with-more-information-than-you-need-to-understand-this-other-required-portion).
Personally, I don't want to jump around to 50 different locations on the web to try and conjure up a piecemeal solution that I believe works, only to be proven wrong later. I want to know what to do and why it works. I've tried reading the documentation, and have given up on it, because to me, it seems to assume that the server has already been set up by a database administrator.
Instead of articulating my problem directly (as I seem to be having more trouble than I would like by trying to do so), I believe it would be easier to articulate my problem indirectly by stating what my expectations would be after installing PostgreSQL for the first time.
So to start, I will mention that I'm running Ubuntu 18.04.6 LTS, and am installing PostgreSQL 14.1 with the following command:
sudo apt install postgresql-14
Before continuing, I would like to add a side note in advance, that I do not want suggestions for an alternative OS or install method. I just want to be able to get "up and running" in a common-sense fashion from this exact point.
Moving on, I know that the aforementioned command creates a *nix user called postgres.
From here, I can now indirectly state my problem using an outline of what my goals and expectations are immediately after installing the software via that command.
After installing PostgreSQL via apt, these are my expected goals:
I want any client to be able to connect to the database server from any computer where a route exists from the client to the server.
For the sake of simplicity with these stated goals, when it is directly or implicitly stated that I am trying to connect a client to the database server, I am making the assumption that the client is able to, at a minimum, ping the machine that the server is running on, and vice versa.
For now, I'm not completely worried about the database being accessible from the public Internet.
I expect to be able to access the database from any computer on my LAN, whether it is an actual LAN, or some sort of logical LAN (like a WAN or a VPN).
If I change the PostgreSQL password of the postgres user, I expect that any client logging into the database server via the postgres user will require the password.
This means if I want to change the password to some_password via \password postgres or ALTER USER postgres WITH PASSWORD 'some_password'; (I am assuming this is how you change the login password of a PostgreSQL user), then...
I expect running psql [-h host] -U postgres -W from any host...
That when I am prompted to enter the password...
I can only log in by entering the exact password of some_password.
Entering any other arbitrary text for the password should not allow me to log in.
I am adding this as a requirement because previous install attempts have shown me that this is NOT the case.
I expect to be able to create a PostgreSQL user account other than postgres (e.g. db_user) with a password and have it be subject to the same requirements as the postgres user.
i.e. once the new account is given permission to log in, the same common-sense login requirements to log in must be imposed, i.e. you can't get in if you don't have the correct username/password combination.
If the process to achieve the aforementioned can be explained in such a way that it can be understood with minimal mental friction, I would be extremely grateful.
Feel free to assume that my knowledge is on par with that of a undergraduate CS student who just completed their first year of university, who also understands Linux filesystems and basic computer networking. I just want the answer to be as accessible to as many people as possible, as I am sure I'm not the only person who has struggled with installing PostgreSQL, in spite of having a power user's level of computer literacy.
sudo apt install postgresql
sudo -u postgres psql
Set a password for this user with \password or the other method you mention
sudo vi /etc/postgresql/10/main/pg_hba.conf
Make the only uncommented nonblank line in this file be host all all all md5
sudo vi /etc/postgresql/10/main/postgresql.conf
uncomment listen_addresses line and set it to '*'
sudo service postgresql restart
When you make a new user, you should also make a new database which has the same spelling as the user does. Otherwise you will need to specify the database name when you try to log in with psql -U, such as psql -U newname -d postgres -h[hhh]. Should you actually be running 14 not 10, then you will need to change the paths of the config files you need to edit accordingly.
This question already has answers here:
Export and import table dump (.sql) using pgAdmin
(6 answers)
Closed 1 year ago.
Let I first state that I am not a DBA-guy but I do have a question regarding restoring remote databases using PG Admin.
I have this PG Admin tool (v4.27) running in a Docker container and I use this portal to maintain two separate Postgress databases, both running in a Docker container as well. I installed PG Agent in both database containers and run scheduled daily backup's, defined via PG Admin and stored in the container of each corresponding databases. So far so good.
Now I want to restore one of these databases by using the latest daily backup file (*.sql), but the Restore Dialog of PG Admin only looks for files stored locally (the PG Admin container)?
Whatever I tried or searched for on the internet, to me it seems not possible to show a list of remote backup files in PG Admin or run manually a remote SQL file. Is this even possible in PG Admin? Running psql in the query editor is not possible (duh ...) and due to not finding the remote SQL-restore file I have no clue how to run this code within PG Admin on the remote corresponding database container.
The one and only solution so far I can think of, is scheduling a restore which has no calendar and should be triggered manually when needed, but it's not the prettiest solution.
Do I miss something or did I overlook the right documentation or have I created a silly, unmaintainable solution?
Thanks in advance for thinking along and kind regards,
Aad Dijksman
You cannot restore a plain format dump (an SQL script) with pgAdmin. You will have to use psql, the command line client.
COPY statements and data are mixed in such a dump, and that would make pgAdmin choke.
The solution by #Laurenz Albe points out that it is best to use the command line psql here, and that would be my first go-to.
However, if for whatever reason you don't have access to the command line and are only able to connect to this database via pgadmin, there is another solution which you can find here:
Export and import table dump (.sql) using pgAdmin
I recommend looking at the solution by Tomas Greif.
I am trying to export my Postgres table to a csv on my desktop and I get this error:
ERROR: could not open file "C:\Users\blah\Desktop\countyreport.csv" for writing: Permission denied
SQL state: 42501
This is my query which I believe is the correct syntax
COPY countyreport TO 'C:\\Users\\blah\\Desktop\\countyreport.csv' DELIMITER ',' CSV HEADER;
According to the user manual:
Files named in a COPY command are read or written directly by the
server, not by the client application.
https://www.postgresql.org/docs/current/static/sql-copy.html
The common mistake is to believe that the filesystem access will be that of the (client) user, but it's not. It's normal to run the postgresql server as its own user. Therefore action carried out by the server will be done as a different OS user to the client. The server is usually run as an OS user postgres.
Assuming that you are running the server on your local machine then the simplest way to fix it would be to give postgres access to your home directory or desktop. This can be done by changing the windows security settings on your home directory.
Before you do this.... Stop and think. Is this what you are looking for? If the server is in development then will it always run on the user's machine. If not then you may need to use COPY to write to the stdout. See the manual for information on this.
I have a database file (*.db) that need to be recovered.
The bad is, the end-user have null idea of the version of the database. Not know the password. The original developer is lost. The computer where was installed was formatted. We have not experience in this database software. Yeah, nightmare.
My guess is a old database. I'm trying to open it in Sybase 11, dev edition.
I follow this steps: http://dcx.sybase.com/1101en/sachanges_en11/unloading-reloading-upgrading-newjasper.html
I try to use the UNLOAD utility from command line & from the Sybase central utility. From command line I do:
./dbinfo -c "DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB;UID=DBA;PWD=sql"
SQL Anywhere Information Utility Version 11.0.1.2045
Unable to start specified database: '/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB' was created by a different version of the software
Ok, I try to unload:
./dbunload -c "DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB;UID=DBA;PWD=sql" -n /Users/mamcx/Desktop/
SQL Anywhere Unload Utility Version 11.0.1.2045
Connecting and initializing
***** SQL error: Unable to start database server
Ok, from the server admin tool:
dbunload -v -c "UID=dba;PWD=***;DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB" -an "/Users/mamcx/Desktop/baba.db" -ap 4096 -ea None -ii -sa -so _sc866192545
Connecting and initializing
***** SQL error: Unable to start database server
An error occurred while attempting to unload the database '/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB'.
Exist a way to know the version of the database server used to create this? Is possible to recover this file?
I don't know how to get the version out of the Database File if you are not able to start it.
You could get a hint from the hopefully existing Client PC's. Check the ODBC Driver Version they have installed.
I had good success with the support of Sybase. If you or your client has a support contract you can get them involved.
HTH
Try to simply start a server with that database and capture the output with -z -o server.out. The server.out file should contain a more specific error telling you why it can't start the database. This error can occur if you are trying to start something that is not a SQL Anywhere database.
You may also want to post this question over at http://sqlanywhere-forum.sap.com/.