Newbie question:
I have a group of notebooks that I'd like to connect to a single server and database in the same ADS session, structured like chapters in a book. For a single notebook, I can specify and connect to a database, and execute code cells successfully.
When I open another notebook (appears as a new tab within the current ADS window, same folder and workspace), I do not see the connection I defined previously in the "attach to" dropdown list. I have to go through the connection wizard again to enter the server and authentication details.
Also, the previously defined connection does not show-up under recent or saved connections, even after checking "remember password" when setting up the connection. Has anyone seen this behaviour before?
I haven't found any documentation on managing multiple notebooks. Am I going beyond how notebooks are supposed to be used?
Thanks.
Version: 1.21.0 (system setup)
Commit: 2413919f186f780f0193d047da3d90bb3c1e9bf6
Date: 2020-08-11T20:52:47.502Z
VS Code: 1.48.0
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.19041
There is a setting within the File-->Preferences-->Settings called "Notebook: Save Connection Name". (You can search settings for that name) Once that is toggled, the notebook will remember the connection name that you used.
This assumes that you have saved and named connections in the first place.
Related
This particular application is used to created users. And it had UI to display the list of all users created. When we create a user using New and Accept buttons, it is not updating the list nor it is updating the database. We have enabled TLS 1.2 and so using ODBC Driver 17
When I changed the driver to simple "SQL Server", then all the previously non-displayed users also got added to the list and database as well.
when I debugged the code, it is failing at one particular line of code - SQLBulkOperations i.e,
As an alternative, I changed the code to
result = SQLSetPos(m_hStatement, 1, SQL_ADD, SQL_LOCK_NO_CHANGE);
It is able to add the users to database, but the problem is, the users data is not syncing to the server.
Note: We have restarted the NodeSynchronizer service. All the configurations are correct.
Please help.
I am trying to install MediaWiki version 1.31 localy and I have run into some issues that I cant get past by. Mainly when I input datatabe connection (I am trying to connect to PostgreSQL database) information it returns this error.
Thing is the port I am trying to connect is 5433 not 5432, also the names "template1" and "postgres" are not included in my input trough the dialogue screen - I dont know where they came from. "test1" is the name of the database I am trying to connect to.
Any help or advice how to get trough this error would be greatly appreciated. Thank you.
That the port you specify is not used while setting up the database schema in the first place is a long-standing known bug. One workaround is to run your database on the default port until you have wiki set up, then change it back to the port you want.
In order to create a new database, you need to connect to an existing database in the same cluster. 'template1' and 'postgres' are pre-existing databases (usually created at the time the cluster was created) commonly used to connect to in order to create a new database. These names are "well-known", you don't need to specify them.
I have been using SQL Server Reporting Services on many servers but on this particular one when I try to open the url to create subscriptions I get the following error:
HTTP Error 500.24 - Internal Server Error An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode
Any advise would be greatly appreciated, please advise if more information is required
One option would be to simply switch your Managed Pipeline mode from Integrated to Classic in IIS.
The steps would be as follows.
Start the Internet Information Services (IIS) Manager from the Start menu on the Windows machine.
Click on Application Pools from the left menu and select the application you are working on from the middle table.
Right-cick to bring up the "Set Application Defaults" menu.
Change Managed Pipeline Mode from "Integrated" to "Classic" and press OK.
You will then see the Managed Pipeline column for that item change from Integrated to Classic.
This should at least get rid of the error message, without diagnosing the cause (which would require a lot more information).
Issue resolved, I had to create the virtual directory for Report manager URL.Once I added the virtual directory name and clicked apply, the report manager opened in IE.
I deploy a report solution from Visual Studio report builder and upload several reports onto SSRS.
I try my connection but failed and other previous reports which used different connection setting worked.
Please see below the two connection settings: The first figure is mine and the second figure is others'. The only difference is the 'Data Source' in 'Connection String'. Can you please advice why this cause the problem and how I can fix it? If I use 'localhost' to create my data source in my local desktop, the report cannot be compiled successfully.
This issue seams with user RepoerReader.
At your local database you have crated user RepoerReader
But your remote database located 10.12.13.14 database you you do not have user RepoerReader and are you sure and make sure port is correct or your password is wrong.
I fixed the problem by the following tricks:
When you first time deploy the solution, you should set the properties properly, like figures showing. Normally, I only configured 'Debug' because I use a single server for both data source and report delivery.
Set TargetServerURL with the client end IP address unless you are on the server itself which can be 'localhost'. This would make sure you deliver the reports to the right remote server withour error.
Login the SSRS and check the data source loaded. Normally, SSRS would automatically change the IP address into 'localhost' which is good to go for report viewing. If it still was the IP address as what I described in the question, you can try to go back to the Visual Studio report builder and change the IP address into 'localhost'. Then, don't preview the report but directly deploy the solution which ensure the new data source takes 'localhost' in SSRS. For the report was ever deployed to a specified server, so 'localhost' would not make any ambiguousness and the deployment can still locate the same server to renew the stuffs in SSRS. A key thing here is to reset the 'OverwriteDataSource' into 'True'.
Hope this help. Cheers
I am a .Net / SQL Server programmer. I am trying to make an Access database created by someone else to work. It looks like is uses a procedure similar to Save password for ODBC connection to SQL Server from MS Access 2007 but I am using Access 2003 so I suspect something else needs to be done. I don't really know what I am doing with Access but I am stuck with it.
I do have an ODBC connection and it looks like the linked tables use it. The database has an AutoExec which populates some local tables from the linked tables that the reports use. It also calls a qryConnect with a dsn-less connection like the linked article and this seems to work. I have got it to stop asking for a user and password on start up. I can also open most reports without problems, 2 do not work. A form loads on Startup with buttons that basically show reports. This is where it gets odd.
The reports fail from the ODBC driver with the windows credentials. Then a logon box shows up with the correct user (a user with read only privileges) but the trusted connection box is checked. I do not have the trusted box checked in the DSN. Not do I have Trusted_Connection=Yes in the DSN-less connection in qryConnect.
This is the code in the form
stDocName = "rptNegativeLotQtys"
DoCmd.OpenReport stDocName, acPreview
I don't know how I buggered it up so much and before I try again copying everything to a new mdb and trying again I am hoping to get some guidance.
On a side note I can open everything fine on my machine. I am an administrator as far as Windows is concerned but not SQL Server.
EDIT:
I created a new DSN just for these reports. Then I deleted all linked tables and re-linked then using the new DSN. I looked at the linked tables in MsysObjects and the new DSN is listed there. Yet Access still prompts for the password. It appears that it is not caching the password.
Actually, you do NOT need to add nor store the UID/Pass in the connection strings used. However, what you MUST ensure is that all connection strings are the SAME. If they are different, then the cached UID/password will not work.
Also, make sure you do NOT connect nor open a table AFTER having connected using Windows Auth – the reason being then when you add the table links (especially via code), then the cached setup of using windows auth will occur, and thus prompts will occur when the links suggest to do otherwise. In other words linking and attempted to use SQL logons will NOT work if you already opened any table link via windows auth (so exit the database and do NOT open any table that could/can use windows auth).
So I would delete the links, and re-create them – but again, ensure that you never connected as a windows auth user to SQL server.
So the "cache" that access has is a GREAT friend/feature to eliminate the need to include UID/pass in the connection string - but the SAME feature will bite you VERY bad if you at any time connecte to the database in question via windows auth.
How to “cache” the user logon and ID is explained here:
Power Tip: Improve the security of database connections
http://blogs.office.com/b/microsoft-access/archive/2011/04/08/power-tip-improve-the-security-of-database-connections.aspx
So you “can” include the UID/LOGON in the linked tables, but above shows that a ONE time logon can also be used. So be VERY careful when setting up table links – due to the above “cache” of the user and HOW they logged into the database – code that ATTEMPTS to create table links based SQL logons will actually wind up using windows auth if you already connected as such (so exit the database if you going to re-link using SQL logons).
Keep in mind, Access does NOT use the DSN AFTER you linked the table. The information from the DSN is a ONE TIME copy to the connection string. You can verify this by going into my documents and deleting the DSN you used. Assuming the linked table was working correctly, you find that they CONTINUE to work EVEN if you delete the DSN. In effect this means that linked tables are DSN less except for when you create the linked table. This allows you to easy copy the application to different computers without having to copy the DSN.
As to ensure that all the linked tables use the same connection string, it is a simple matter to delete them all, and re-link.
You can also hit ctrl-g to bring up the debug window, and look at the connection string this way:
? currentdb.TableDefs("linked table name").Connect
the result in the debug window for a windows auth connection string will look like this:
ODBC;Description=test DSN;DRIVER=SQL Server;
SERVER=albertkallal-pc\SQLEXPRESS;
Trusted_Connection=Yes;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Note how in above we see "trusted connection" (that means windows auth).
If I linked the table using SQL logon (and REMEMBER to check save password), then you see this:
ODBC;Description=TEST3;DRIVER=SQL Server;
SERVER=ALBERTKALLAL-PC\SQLEXPRESS;
UID=MySQLogon;PWD=MyPassword;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Just remember during the table link process to "check" the save password.
eg this: