This question already has answers here:
Where are My.Settings saved in VB 2010 .NET?
(4 answers)
Closed 8 years ago.
I am creating a VB.net application and including my database credentials in the settings of the project, so to access i use:
My.Settings.SettingName
Is there any way a user using the application can view these settings?
I am worried about someone being able to log into the database if they ever manage to see the settings?
Application users can not see these settings. The only way to see the settings is to look at the code as a developer.
EDIT:
In my humble experience, the best choice for hiding a connection string in your app, considering the environment I work in, is to hide it in the vb code. You can make a database utilities class, and put your methods and properties there - methods being connect, execute commands etc, and a private property which is your connection string that other methods in the class use.
Other people can see the connection string, like other developers, or people who are browsing around the same files you have access to, but upon deployment, it will be very difficult for someone to extract the connection string out of yourapp.exe.
Related
I have very a rudimentary understanding of Microsoft Access and VBA Code.
On my work desktop, I have Microsoft Office Professional Plus 2013 Access
I've been tasked to create a MS Access application with an Access DB.
I started developing an MS Access application with Forms , and the corresponding DB
I'm using VBA code event handlers(or Event Procedures) for the UI control buttons.
I wanted to create a common configuration settings area for said application( like ASP.NET web application have web.config files or app.config files )
I failed to find anything similar for MS Access application development.
Could someone please provide me with an explanation as to how to implement an MS access implementation model/software design pattern for common configuration settings area that is modular, reusable, clear and concise?
As noted, I great way to do this is to simply create a table in the front end. It is assumed that you will split your database into two parts. The code/forms etc. is the so called front end,and then you have the back end part (the database - it can be a accDB file, or it can be say SQL server).
So the typical update and deploy of your software will be:
Re-link your tables from test database to the actual live production database.
Compile your accDB into a accDE.
Deploy this new updated "next" version of your software to all the desktops.
So, since any change or addition to settings will be in the new front end then any application wide settings you have will thus roll out with your update.
It often depends on the user base. In the case that we had multiple customer sites running our software, then using a local table would not suffice, since things like path names, connection strings to the database etc. are customer specific. So, in this case we moved the settings table out to a text file (setup.ini). So we now use a setup.ini file that is external to the program and assumed to be deployed in the same folder as the front end. On startup we use the windows API to read ".ini" files.
So, both ideas (external setup.ini) or a local table in the front end are rather good choices from a development cycle point of view.
So once you down the road in developing your application, and the table/data structure changes are down to a dull roar, then it is time to split your application. (use the built in split wizard for this). I will say that even for my .net applications, I still often use a external setup.ini file for settings, since once again with multiple customer sites, it not practical to have customer specific settings in the application as opposed to a external settings file.
Background
I have an Excel application that connects to SQL Server using ADODB Connection via VBA. This ADODB Connection contains credentials that are hard coded. I know this is not best practice.
Issue
It has come to my attention that there are some users that are using this method to access password protected VBA modules, and retrieve connection credentials. Which they use it to access the server.
Possible Solution?
I am considering possible solutions to hide the connection string from VBA or set up a secure connection string using this method.
I wonder if it is possible to build this class with the credentials built in, so that in the VBA we do not hard code the credentials, rather just refer to this connection class?
Anyone here has experience with this?
I have looked at this solution. However, I am using a 2017 version of Visual Basic and I am unable to follow the step-by-step guide. In particular, I was unable to find the activeX reference.
I would really appreciate any help with this.
Many thanks.
I am coming from a php background background where we remotely connect to the database and manipulate everything with php code. Now in vb.net, will the performance of my desktop application be affected in anyway if i connect manually in the form_load event event instead of vb.net database source connection?
i come from both backgrounds.
yes you can manually open database BUT
you should specify the database you are using to make the best performance in your desktop application, for example:
in access database (mdb files), you should open the database once in form_load, and use it all the time, then close it before exitting the application in form_closing (this is for better performance)
while in SQL Server, you should open the database for each function then do your queries then close it after you finish.
Create a DataAccessClass.
Do your db functions in this class (update functions, select functions etc)
Connect to the db on class instantiation.
give your class the necessary work to do, and receive answers back from the class.
In essence, extract your data access from your forms, so that you can reuse your data class anywhere in your app
I am here to write a small database application that will be running in desktop (offline mode).
I am using MSAccess 2007 as my database file and trying to write code in vb.net.
I used to write the code vb6 an usually had global variables for storing database connection and executing every query from that.
I am trying to upgrade myself from vb6 to vb.net.
do i need to read some more simple starter books also?
In .NET, talking to a database is handled with ADO.NET, which uses something called "connection pooling". The connection pool is basically a collection of open connections to your database that ADO.NET manages for you. In your code, when you create and open a Connection object, ADO.NET first looks in the connection pool to see if it already has an open connection to your data source, and if it finds one it uses that (instead of actually creating and opening a new connection). When you close your connection, ADO.NET does not really close it, but instead returns it to the connection pool.
Therefore, you do not need (and in face do not want) to maintain open connection objects inside your application (in a global variable or anywhere). The correct approach with data access in ADO.NET is to create and Open a Connection object, do whatever you need to do with the database, and then Close and Dispose your Connection.
Store the connection string in the config file (in the solution explorer, open the My Project folder and doubleclick on Settings.settings).
I'd suggest that you create one or more classes to contain your database code and let those classes convert between the database data and your application objects, most VB6 projects I saw had the GUI hard linked to the DB which can make future maintenance or new features very difficult and limits the possiblity of code reuse.
If you've got VB6 experience I'd thought that you could probably start trying to create the application right away but you should definitely read either a good book or good articles about it at the same time so that you pick up things like that you need to Dispose of your database objects after user etc.
It's probably a good idea to get a book, a lot has changed since VB6.
Also consider using a more robust db, like SQL compact or SQLite. It will allow you you use the Entity Framework which will make writing your app a whole lot easier.
I'm working on a program that needs to edit some objects in an Access database. It also runs a subprogram (long story) that tries to access the underlying JET database while Access still has it open via ODBC.
The problem is that as soon as I start editing Form objects using VBA - for example, using Application.LoadFromText - Access changes the database to exclusive mode. Exclusive mode itself is fine, and I know why it needs it. But I need to be able to switch back to "shared" mode afterwards so that I can run my subprogram.
I've observed that if you use the UI to open a Form in Design mode, Access switches the database to Exclusive. (You can confirm this by trying to open it from another computer.) But when you then close the form designer, Access immediately switches it back to shared mode, which is what I would hope for.
Is there a way to switch it back and forth myself using VBA / COM calls?
I know I can call Application.CloseCurrentDatabase() followed by OpenCurrentDatabase(), but that closes all the windows and upsets the UI, so it's not ideal.
Is splitting the database into a separate front-end with the forms/modules/etc. and back-end with the tables an option? That way if the front-end is locked, the back-end is still accessible. Access has a database splitting wizard for just that.
You might try .UserControl and .Visible. I use them to transfer control in automated processes.