adminer only displays one database - adminer

I download Adminer 4.2.5 from https://www.adminer.org/#download which is just one php file around 414 kB in size. I placed this in /localhost/ and was able to log in to database without any issues. But the only problem is that, I have about 24 databases, and adminer only shows tables and contents from 1 database.
This database also happens to be the first one indexed as it starts with letters ab.. so I am guessing it is only grabbing it, but this is not the database I want to fetch. Is there any solution for this?

Adminer will only ever show one database at a time.
You can switch databases very simply, by using the standard links at the top of your screen (just to the left of your "logout" button). I.e.:
MySQL » Server » yourDatabaseName » Table: yourTableName
In this example, clicking on "Server" will return a list of all of the databases to which you have access.
If you can not see a database which you know to exist, you may have a permission and/or access error.

Found an easy alternative.
While logging in with a username and password, there's an option of typing the database name. If the database exists and the user has the rights, the tables in the DB will open up.

Related

What is "Delete Connection" in DBeaver?

enter image description here
I've loaded databases from several servers. But I want to clean my Database Navigator now.
If I click the Delete Connection, will all the database, table, data in server be deleted? or just disconnect only?
It will delete the connection (that is the line between you and said database) only.

How do I give my MacOS app permission to create "WAL" file to open an SQLite DB with journal-mode=WAL?

I'm an experienced programmer, but this is my first MacOS app (on 10.15.2), which needs to read an sqlite db of the user's choice (potentially anywhere on the machine)
At first it wouldn't open the DB 'name.sqlite' file itself;
but when I used NSOpenPanel to let the user select it, that worked.
But then the query failed because sqlite3 (via SQLite.swift) was trying to open 'name.sqlite-wal'
os_unix.c:43353: (0) open(/path/to/dbname.lrcat-wal) - Undefined error: 0
If I open the db using the command-line client, and pragma journal-mode=off then the app works fine, but I can't restrict the app based on that - most of the dbs have WAL journalling
I tried turning com.apple.security.app-sandbox false in app.entitlements, but that didn't help.
I tried moving the db to the Pictures folder and turning com.apple.security.assets.pictures.read-write true, but that didn't help.
The unix permissions for db and the containing folder (/tmp in my test) are both good.
Because allowing the user to select the db via the NSOpenPanel allowed me to open the db for reading, I assume there's a similar restriction on the creation of the '-wal' file for writing.
How can I get permission (ideally without bothering the user with details of what a wal file is) to create the file next to the db?
Edit:
Following TheNextMan's suggestion about sidecar files, I searched again.
The WWDC presentation he (guessing the pronoun) linked shows how to use CFBundleDocumentTypes to relate extra extensions with NSIsRelatedItemTypefor NSFilePresenter, but (as far as I know) I'm not going through that route. I've tried it but it hasn't helped
I also, armed with the "sidecar" search term, found Access sidecar files in a Mac sandboxed app, which looked good but didn't help.
Even better I found the four-year-old unanswered duplicate of my question (if I had enough rep I'd mark this as a duplicate), SQLite and Sandboxed OSX apps, which includes a quote from Apple documentation App Sandbox Design Guide, saying
Note: In the case of a SQLite journal file, beginning in 10.8.2, journal files, write-ahead logging files, and shared memory files are automatically added to the related items list if you open a SQLite database, so this step is unnecessary.
So apparently it should Just Work™. But it doesn't.
Thank you for this thorough question. I encountered today the same issue as you, fighting the macOS sandbox restrictions. Similar to you, I've already copied the user selected (NSOpenPanel) database to my apps temporary folder (FileManager.default.temporaryDirectory).
But still I was unable to query the database file: sqlite3_prepare_v2 always returned the os_unix.c:45340: (0) open(/var/folders/.../myDB.db-wal) - Undefined error: 0 message.
As the database already is located in the temporary folder, which definitely is writable by our app (as we copied the database file!), we can simply create the myDB.db-wal file ourselves:
let tmpLocation = /// URL of the SQLite *.db file in a writable directory
let walLocation = tmpLocation.deletingPathExtension().appendingPathExtension("db-wal")
try Data().write(to: walLocation)
Et voilà: opening the DB is working.

HeidiSQL 10.2 with Postgres doesnt show newly created database

I connected PostgreSQL to heidiSQL and each time I create a new Database, it does not appear in the database list, even after refreshing or restarting Heidi.
If I try to create it back, it tells me that the database already exists.
I really don't know what to do by now
Most probably you told your session to display only one or some of all databases:
Remove these, or add the newly created database there to let HeidiSQL display it.

Typing in password for every connected table from SQL Server 2008 R2 in Excel 2010 Powerpivot Addin

I've got a BI Dashboard in Excel 2010 using Powerpivot, which is connected to a number queried tables on one SQL Server. When the connections were setup, I checked the box to 'save password' on each one. However, whenever my users reopen the document and go to the Powerpivot window and select 'RefreshAll' then they have to type in the password multiple times (once for each table), which is not suitable.
I have looked here and here and seem to be experiencing the same issue as a number of other people. I have started again from scratch, ensuring that the 'save password' box is definitely checked on each connection string.
The only workaround I can think of is by user Windows Authentication, but this document is intended for widespread use, and as such this will require a lot of maintenance, and will really annoy my server admin :)
Does anyone have a workaround, or any way of resolving the problem?
This solution comes close, but doesn't seem to work in my case. Might work for others though...
Solution summary:
In the main Excel window in the Data tab, choose Connections, then select the workbook connection that corresponds to your PowerPivot connection. Click on Properties, switch to the definition tab, and mark “Save password” box.
Source:
http://cpa-it.com/password-not-saved-in-powerpivot-connection-when-using-sql-authentication/#comment-10654
I've found a workaround that works for me, but might not be an ideal solution for others.
In the main Excel window, you can create a new connection using a connection file (.odc). If you create this file on a shared network drive that all users can access, and select to store the password in the connection file, the password is -actually- stored.
You can then go on and use this connection in the PowerPivot window. It will no longer ask for a password when refreshing your tables.
Of course this is only a useful workaround within a company LAN, and if there are no security implications for storing the password on a fileserver in an odc file.

SQL Server Management Studio - Server Names Disappeared

The first dialog box you get when opening SSMS (mine is 2008 R2) allows you to choose which server you want to connect to.
I had at least six servers in that list, including a local server called something like MYPC/SQLSERVEREXPRESS
Windows Updates ran last night and rebooted my machine, and now my SSMS list of servers is gone. I can select (local) or (browse for more)
What happened to my previously saved servers and their saved login info?
The file that stores these for 2008 is found at c:\%UserProfile%\Microsoft\Microsoft SQL Server\100\Tools\Shell\SqlStudio.bin
My guess is that it is still there, but was overwritten by one of your updates, you can check it to see when it was last modified.
You should make use of registered servers and export the file to save time if this happens again.
As I understand, you want to retrieve your credentials from that file.
There is a way to restore your passwords, if you still have sqlstudio.bin file and you can see "password" entries there.
First, some theory: When SSMS saves connection object it encrypts the password using some encryprion method, that is BOUND to your windows login. If you try to copy the sqlstudio.bin to other machine/user profile, passwords will not be decrypted. So it is important that you do all actions under same windows account, that you have used then sqlstudio.bin was generated. I can not tell you, if you can directly manipulate sqlstudio.bin - I suppose there are some checksums there which will prohibit direct manipulation, but there is another way.
I know the information I written above, because I develop myself an add-in for SSMS - SSMSBoost. I have implemented there the logic to manage preferred connections (so that you actually will not need standard dialogue anymore). I use exactly the same SSMS objects to store connections and serialize then into XML, so it is easier to manipulate.The picture below shows contents of sqlstudio.bin and SSMSBoostSettings.xml for the same connections. You can recognize, that username and password binary data are the same. So, to restore your password you have to:
install ssmsboost
add preferred connection to ANY database with sql server security
open SSMSBoostSettings.xml (you will see the path to that file in settings dialogue, after you have saved settings. Just save, close and re-open it. Path is displayed at the bottom)
Close SSMS, open sqlstudio.bin and ssmsboostsettings.xml in editor
modify entry in ssmsboostsettings.xml - enter data of your server from sqlstudio.bin - adress, database name, username. Carefully copy password data.
save xml and open SSMS - SSMSBoost will now show your connection in preferred connections and you will be able to connect to database. (see second picture)