New to MySQL
-
Hai Guys.
I'm having alittle trouble with my MySQL Server. I can connect to the server fine on any computer in my network through the command prompt but I have not been able to connect through my front end VB.Net program.
Code:
ConString = "Server=192.168.0.4;Database=WTF?; User=WTF?;Password=WTF?;"SQLConn.ConnectionString = ConStringSQLConn.Open()I've tried just about everything google has to offer, including the above code and more. I get a connection error exception with a comment about 'check the MS SQL Server 2005 settings'. I do not have that server installed on my network. Is there some setting I need to change in visual studio? I tried phpmyadmin but opted to something more familiar (.net).
And to reiterate (or I guess iterate) I can connect through the command prompt using the username, password, database and server just fine.
mysql -h 192.168.0.4 -u WTF? -p WTF?
use database WTF?;
All work fine...
-
You are using the MySQL connector right?
MySQL != MSSQL, you cannot use the same references.
http://dev.mysql.com/downloads/connector/net/1.0.html
-
Ahh, so .net doesn't come with MySQL support?
that answers a lot of questions. I'll try that.
-
I agree, I think you are using the MSSQL API, not the MySQL API. That would explain the error message telling you to check the settings for MS SQL Server.
As an aside, who started the practice of including the password in some sort of connection string?
@alehx said:
ConString = "Server=192.168.0.4;Database=WTF?; User=WTF?;Password=WTF?;"
It seems that every SQL API documentation I have read include examples where one has a string hard-coded into the program with the password, or has the user enter the password as another command-line option? Doesn't this encourage bad security practices that find its way elsewhere?
-
@alehx said:
Not exactly... just that the object you used was for MS SQL. It is like using a screwdriver for tightening bolts... it just won't work. Check out the MySQL website for suggestions for what to use for VB.NET.Ahh, so .net doesn't come with MySQL support?
that answers a lot of questions. I'll try that.
-
I might be new to this but it might clear up any questions I had.
On the host machine, I allowed user 'U' all privileges on the 'D' database. I have no idea about the security ramifications of hard coding passwords and such, but wouldn't one think that if user U is only allowed to access database D any damage would be limited by input checking and "hiding" or rather putting sql statements in the limited user functions? As long as I don't write bad statements the user is really only able to save, update, and retrieve and all of that is controlled by my functions. Even more so what if I only granted user U extremely limited functions?
-
@alehx said:
I might be new to this but it might clear up any questions I had.
On the host machine, I allowed user 'U' all privileges on the 'D' database. I have no idea about the security ramifications of hard coding passwords and such, but wouldn't one think that if user U is only allowed to access database D any damage would be limited by input checking and "hiding" or rather putting sql statements in the limited user functions? As long as I don't write bad statements the user is really only able to save, update, and retrieve and all of that is controlled by my functions. Even more so what if I only granted user U extremely limited functions?
You should always deny user privileges where they are not needed as you should never take it for granted that your code is 100% perfect. You may easily leave your code open to SQL injection attacks. Such an attack may allow a user to drop an entire table or entire database. Just limit any user to only have privileges to SQL commands that are actually used by that user. "hiding" is commonly reffered to as 'security by obscurity' which is no security at all.
-
@WeatherGod said:
As an aside, who started the practice of including the password in some sort of connection string?
I am sorry... Where would you put it?
-
I would also normally consider having a readonly database login for any end user action that does not require any writes to the database and a second login for the same end user for any queries that require write access. This will limit damage if you happen to leave a possible hole in your security.
-
@Hitsuji said:
I would also normally consider having a readonly database login for any end user action that does not require any writes to the database and a second login for the same end user for any queries that require write access. This will limit damage if you happen to leave a possible hole in your security.
That's just ridiculous.
-
@MasterPlanSoftware said:
Well, if it was a program where the user establishes the connection, I would have the user enter the password at run-time. If it was an automated task, then there are less options available. But hard-coding a password into your program isn't the best practice, and I would rather the documentations show good ways of obtaining passwords from users in order to educate newbies in security. SQL is one of the first places a programmer will encounter tasks involving password handling, and as such they will be highly influenced by some of the first examples they see.@WeatherGod said:
As an aside, who started the practice of including the password in some sort of connection string?
I am sorry... Where would you put it?
I am not a security expert by any means, but I just never felt comfortable with such a practice, that's all.
-
@morbiuswilters said:
That's just ridiculous.
Why? You don't like to take a couple extra steps to make your database less secure while smugly patting yourself on the back and giving bad advice to strangers on the internet?
-
@WeatherGod said:
I would have the user enter the password at run-time.
Why on earth should your user know the password to your database server?
@WeatherGod said:
But hard-coding a password into your program isn't the best practice,
Agreed. But you are arguing about connection strings, which are stored in configuration files.
@WeatherGod said:
I am not a security expert by any means, but I just never felt comfortable with such a practice, that's all.
Nor do you have any idea what you are talking about.
First MSDN hit: http://msdn.microsoft.com/en-us/library/bf7sd233.aspx
@TFA said:
Default Configuration
Connection strings that are contained in a parent configuration file are inherited, unless the clear element is used in the child configuration file. The following default connectionStrings element is configured in the Machine.config file.
You can access the connectionStrings element programmatically. For more information, see the ConnectionStrings example.
<connectionStrings>
<add
name="LocalSqlServer"
connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
providerName="System.Data.SqlClient"
/></connectionStrings>
-
@MasterPlanSoftware said:
Why on earth should your user know the password to your database server?
They don't... when did I say that? I am talking about that particular user's login to the database.@MasterPlanSoftware said:
Agreed. But you are arguing about connection strings, which are stored in configuration files.
Sorry, I didn't make myself clear... I wasn't talking about ConnectionStrings in the sense of MS SQL. I also don't have a problem with a connection string itself, just the ways it is shown in examples where it is just stored hard-coded or in some sort of plain-text configuration file. All I am saying is that the security implications should be explained for the different ways passwords are placed. Some beginner programmers may not know that one could just put the executable through a strings program and find their hard-coded password.Also, note that I am not a user of MS SQL, so I would not ever come across such an example.
Here are some examples from the MySQL++ API documentation . In it, they encourage the use of a function that parse the command-line to obtain information like the server, username and password. This, to me, is worse than putting the password in the program executable because now the password is in plaintext in the user's history file.
-
@WeatherGod said:
@MasterPlanSoftware said:
Why on earth should your user know the password to your database server?
They don't... when did I say that? I am talking about that particular user's login to the database.Why on earth would the user have a login to the database?
They should a logon to your application, which in turn, has a login to the database.
@WeatherGod said:
just the ways it is shown in examples where it is just stored hard-coded or in some sort of plain-text configuration file.
They are very commonly stored in web.config which is plaintext. Where do you see any kind of security problem?
@WeatherGod said:
This, to me, is worse than putting the password in the program executable because now the password is in plaintext in the user's history file.
How is this any different than:
shell>
mysql --user=user_name--password=your_passworddb_name
-
@MasterPlanSoftware said:
Take yourself out of the context of the business world and place yourself in the scientific research world. We don't have full fledged DBAs, and we don't necessarially have programs that follow typical server-client models. The databases, for us, get treated like data with extra features attached to them. Therefore, multiple users may have read-only access to certain databases, and either directly obtain their data from them, or create their own programs to do it for them. Also, coming up with 'a login to the application' is beyond the scope of most people in this field.Why on earth would the user have a login to the database?
They should a logon to your application, which in turn, has a login to the database.
@MasterPlanSoftware said:
They are very commonly stored in web.config which is plaintext. Where do you see any kind of security problem?
Are they? I wouldn't know... I am not a web developer. I don't know what the security implications of such things. All I know is that I just don't like writing out my password, feels about as bad as leaving a post-it note on my monitor with my password.@MasterPlanSoftware said:
@WeatherGod said:
This, to me, is worse than putting the password in the program executable because now the password is in plaintext in the user's history file.
How is this any different than:
shell>
mysql --user=user_name--password=your_passworddb_nameIt isn't different... that is exactly what I am talking about in my statement. That line gets stored in my shell history file.
-
@WeatherGod said:
Also, coming up with 'a login to the application' is beyond the scope of most people in this field.
Ok, fine, you don't do proper design in your field. Why do you feel the need to try and spread this to new users asking for help?
@WeatherGod said:
Are they? I wouldn't know... I am not a web developer. I don't know what the security implications of such things. All I know is that I just don't like writing out my password, feels about as bad as leaving a post-it note on my monitor with my password.
Alright, well since you don't know, don't sit here giving advice to this new guy asking for advice. There is nothing wrong with storing DB passwords in a web.config.
@WeatherGod said:
It isn't different... that is exactly what I am talking about in my statement. That line gets stored in my shell history file.
But that is MySQL. That is how it works.
There are simple ways around this on the command line, but for you to argue against this in the documentation is stupid. It is not telling you to do this in your own application, it is telling you how to use THEIR PROGRAM.
-
@MasterPlanSoftware said:
Ok, fine, you don't do proper design in your field. Why do you feel the need to try and spread this to new users asking for help?
@MasterPlanSoftware said:Alright, well since you don't know, don't sit here giving advice to this new guy asking for advice. There is nothing wrong with storing DB passwords in a web.config.
When was I giving advice about security? And I never said anything about web.config. Here is my initial statement:
As an aside, who started the practice of including the password in some sort of connection string?
alehx:ConString = "Server=192.168.0.4;Database=WTF?; User=WTF?;Password=WTF?;"It seems that every SQL API documentation I have read include examples where one has a string hard-coded into the program with the password, or has the user enter the password as another command-line option? Doesn't this encourage bad security practices that find its way elsewhere?
I merely asked a question. Nowhere in the MySQL++ documentation and some others that I have read ever say not to do what they do. That is what I am talking about here. Take my statement as me asking for help if you wish. I am genuinely curious about how I should be going about making programs that interact with a database. And why isn't such examples given in the API documentation in order to encourage better design and practice?
-
@WeatherGod said:
When was I giving advice about security? And I never said anything about web.config. Here is my initial statement:
Your posts came off condemning 'connection strings'. And that is wrong.
@WeatherGod said:
I merely asked a question.
That is fine, but there is a specific forum for coding help that you could have posted a new thread and asked for coding help.
That's if you had researched connection strings prior. But you didn't.
Instead you acted like there was something wrong with them while we tried to help someone understand a different topic. The last thing we need to do is make the guy even more confused.
-
@MasterPlanSoftware said:
There is nothing wrong with storing DB passwords in a web.config.
I think I saw something about encrypting the web.config content with the machine specific key somewhere on msdn ...
found it : http://msdn.microsoft.com/en-us/library/dtkwfdky.aspx
if there are no security implications in storing plaintext passwords in web.config, then why did they do that ?
-
@Nelle said:
if there are no security implications in storing plaintext passwords in web.config, then why did they do that ?
Who cares?
Are you incapable of actually thinking this through and making a valid argument? Instead you will just post vague questions based on a google result?
Here, I will humor you:
1) Your webserver should never serve a web.config.
2) Your DB credentials should only be giving you the same access your web app is running at anyway.
3) Anyone who can see web.config you would have to assume is to be trusted with that level.
Therefore if you need to md5 your web.config then you must not trust the people you gave access to your server internally. And that is a whole different level of WTFery.
-
@WeatherGod said:
It isn't different... that is exactly what I am talking about in my statement. That line gets stored in my shell history file.
So what? Why do you think this is inherently insecure?
-
@MasterPlanSoftware said:
2) Your DB credentials should only be giving you the same access your web app is running at anyway.
This is what it boils down to. Guess what, I don't use any passwords on my databases! I use the MySQL root user as well! However, I don't have a problem with security because nobody can connect to my database from outside the network anyway.
-
@MasterPlanSoftware said:
Are you incapable of actually thinking this through and making a valid argument?
you spend too much time arguing with people here.
i was not making an argument, i was actually posting a question, because indeed i am incapable of thinking this through.
@MasterPlanSoftware said:
[...]
Therefore if you need to md5 your web.config then you must not trust the people you gave access to your server internally. And that is a whole different level of WTFery.
exactly...
i could not think of any valid reason to encrypt the web.config (i never encrypt it in projects anyways), still Microsoft introduced this feature.
-
@morbiuswilters said:
Well, if the shell history file is appropriately protected, then it is less of an issue, but I still am hesitent to do so. When it comes to security, I rather listen to the professionals. There is also a lengthy discussion in the MySQL forums about this issue (not particularly with the shell history file, but with other shell issues). The point is that for many newbies, they will read the intro to MySQL where they learn the basic concepts of databases and tables and queries and most likely jump right into it without realizing security implications. Then, when you get into APIs, they show examples where the password is obtained from the command-line or from hard-coded strings, without any sort of discussion of the security issues involved. At the very least, they should point readers to sections in the MySQL documentations to make them aware of such things. It was only my gut instinct when reading the API examples that made me do further research. I worry that others would just blindly follow the examples.@WeatherGod said:
It isn't different... that is exactly what I am talking about in my statement. That line gets stored in my shell history file.
So what? Why do you think this is inherently insecure?
-
@WeatherGod said:
Well, if the shell history file is appropriately protected, then it is less of an issue, but I still am hesitent to do so. When it comes to security, I rather listen to the professionals. There is also a lengthy discussion in the MySQL forums about this issue (not particularly with the shell history file, but with other shell issues). The point is that for many newbies, they will read the intro to MySQL where they learn the basic concepts of databases and tables and queries and most likely jump right into it without realizing security implications. Then, when you get into APIs, they show examples where the password is obtained from the command-line or from hard-coded strings, without any sort of discussion of the security issues involved. At the very least, they should point readers to sections in the MySQL documentations to make them aware of such things. It was only my gut instinct when reading the API examples that made me do further research. I worry that others would just blindly follow the examples.
I still don't follow. Why would having the password in your shell history file matter? Who do you think is going to read it?
-
@Nelle said:
you spend too much time arguing with people here.
You spend too much time making ridiculous and stupid statements here. I don't feel the need to interrupt every thread to tell you that though.
@Nelle said:
i could not think of any valid reason to encrypt the web.config (i never encrypt it in projects anyways), still Microsoft introduced this feature.
MS didn't introduce the feature, they were asked questions on it, and added an article to MSDN.WTF are you talking about?
-
@morbiuswilters said:
I still don't follow. Why would having the password in your shell history file matter? Who do you think is going to read it?
Not to mention, you can just enter the username in the command line and skip the password and it will prompt you when it runs IIRC.
-
@morbiuswilters said:
I still don't follow. Why would having the password in your shell history file matter? Who do you think is going to read it?
For csh and bash, the user's history file is readable by only the user by default. That's well and good, until somebody cracks your login account, or if by mistake I left a terminal open or such. At that point, my MySQL password becomes easily retrievable. If it wasn't there, at least the MySQL database wasn't immediately compromised.Also, when working at the command-line, I often go back to previous commands. What if in such process during pair programming or such I accidentially scroll up to the command where I used the password? I know these are remote hypotheticals, but with the other security implications with respect to viewing user processes and such, and with perfectly sound alternative methods available, there really isn't any good reason to put the password at the command-line.
-
@MasterPlanSoftware said:
Not to mention, you can just enter the username in the command line and skip the password and it will prompt you when it runs IIRC.
Yes, exactly. The -p / --password flag is mostly meant for automated scripts, although I don't mind having it in my command line.
-
@WeatherGod said:
That's well and good, until somebody cracks your login account...
If your login account is cracked the person can easily steal your passwords in other ways.
@WeatherGod said:
or if by mistake I left a terminal open or such.
@WeatherGod said:
What if in such process during pair programming or such I accidentially scroll up to the command where I used the password?
In both cases the supposed attacker has physical access to the machine, rendering any kind of software-based security model useless.
-
@morbiuswilters said:
In both cases the supposed attacker has physical access to the machine, rendering any kind of software-based security model useless.
Ok, fine... I never really thought through how one would obtain the password from the history file, only that I knew the password was there. When it comes to security, I rather be cautious. Anyway, one can still use the ps command without having physical access to get the command, they only need to be logged into the same machine you are using, which may have multiple users. The point is that I am going to follow the advice of the professionals:All in all, the safest methods are to have the client program prompt for the password or to specify the password in a properly protected option file.
-
@WeatherGod said:
The point is that I am going to follow the advice of the professionals:
You can do whatever you want. Next time please don't derail a serious question thread just to spout about things you are unclear on.
-
Hmm well I didn't anticipate the arguements and I'm sorry for creating them.
This is very interesting stuff though. It seems to me like it's one of those never ending cycles.. if you keep adding security where do you stop? I may be mistaken, however.
Being as I haven't taken any formal db class (yet), hopefully delving into it as a hobby before I do so isn't destructive.
-
@alehx said:
Hmm well I didn't anticipate the arguements and I'm sorry for creating them.
This is very interesting stuff though. It seems to me like it's one of those never ending cycles.. if you keep adding security where do you stop? I may be mistaken, however.
Being as I haven't taken any formal db class (yet), hopefully delving into it as a hobby before I do so isn't destructive.
Don't be concerned with much of this... What you need to remember is as soon as your DB code is connecting correctly and everything, the connection string(s) should go into your app.config or web.config.
Don't hardcode them.
-
@MasterPlanSoftware said:
You spend too much time making ridiculous and stupid statements here.
stupid is as stupid does.
@MasterPlanSoftware said:
MS didn't introduce the feature, they were asked questions on it, and added an article to MSDN.
WTF are you talking about?
so someone asked a question, microsoft added the article to MSDN and the entire encryption/decryption code magically appeared in ASP.NET.
according to you, to introduce new features you only have to write an article on MSDN.
perhaps we need to define what "introducing features" means.
for me introducing features in an application means that a feature that did not xist in a previous version, was added to the new version of an application
ms did introduce the feature in the 2.0 version of ASP.NET framework. it was not available in previous versions.
WTF are you talking about ?
and there is nothing stupid or ridiculous in trying to find out why they did that. i just asked if someone does know the reason behind it.
you do not know the answer either, but it did not stop you from replying. you do not have to reply to every post .. if you do not have anything to say its better to say nothing...
-
@Nelle said:
stupid is as stupid does.
Well you sure have me beat there.
@Nelle said:
microsoft added the article to MSDN and the entire encryption/decryption code magically appeared in ASP.NET.
These are the kinds of comments that make the whole IRC channel and most of the forum laugh at you.
Yes, Microsoft added encryption and decryption just on a whim because a reader wanted to know how. That has to be the stupidest comment I have heard in a long time.
@Nelle said:
according to you, to introduce new features you only have to write an article on MSDN.
perhaps we need to define what "introducing features" means.
for me introducing features in an application means that a feature that did not xist in a previous version, was added to the new version of an application
Encryption/decryption was always a part of the framework, so no new 'feature' was added.
Try knowing what you are talking about before running your mouth.
@Nelle said:
ms did introduce the feature in the 2.0 version of ASP.NET framework. it was not available in previous versions.
It was added to aspnet_regiis to do it for you, you could always do this manually if you wanted to.
@Nelle said:
WTF are you talking about ?
Exactly what we were all wondering about you.
@Nelle said:
i just asked if someone does know the reason behind it.
Ask your questions in a new thread. What you did was try and derail a thread. Congrats on that.
Bonus: You also sound like an idiot.
@Nelle said:
you do not know the answer either, but it did not stop you from replying.
You are right, it isn't like I have used it... and actually know about it. You haven't even seemed to read TFA.
@Nelle said:
you do not have to reply to every post ..
No I don't, it is just what I do as a favor to idiots like you who spend all day posting stupid crap to the forum which you clearly know nothing about.
@Nelle said:
if you do not have anything to say its better to say nothing...
Take your own advice here.
I will lock my post to discourage you from posting, as there is nothing left to say on this topic. Since I believe you are nothing but a troll and that you are incapable of ceasing to run your mouth, I am sure you will reply anyway.
-
@WeatherGod said:
You're right. Specifying passwords in the command line is a no-no, especially in shared systems. All I need is ps -fea and I'll see the command line in all its glory, including the password line.Ok, fine... I never really thought through how one would obtain the password from the history file, only that I knew the password was there. When it comes to security, I rather be cautious. Anyway, one can still use the ps command without having physical access to get the command, they only need to be logged into the same machine you are using, which may have multiple users. The point is that I am going to follow the advice of the professionals:
All in all, the safest methods are to have the client program prompt for the password or to specify the password in a properly protected option file.
History files are 700 access by default, so anyone short of root wouldn't be able to read it. Though if someone does have root access, there are other ways to get the password. But not specifying passwords on command line does shield you at least from the common mortal user...
-
@danixdefcon5 said:
You're right. Specifying passwords in the command line is a no-no, especially in shared systems. All I need is ps -fea and I'll see the command line in all its glory, including the password line.
1) Who is running on an untrusted shared system in this day and age?
2) In Linux access to process information should be restricted on shared systems.
3) mysql masks the password in the CLI args anyway so you can't see it even if you wanted to.
-
@morbiuswilters said:
1) Who is running on an untrusted shared system in this day and age?
Doesn't matter... if one account fails, then you are vulnerable.@morbiuswilters said:2) In Linux access to process information should be restricted on shared systems.
Should be... but it isn't by default. At least it isn't for RHEL and FC8.@morbiuswilters said:3) mysql masks the password in the CLI args anyway so you can't see it even if you wanted to.
If you take a look at the pages I mentioned, you would see that the ps command for some systems will look at the strings stored in the child process's address space, but the ps command for other systems look at the strings stored in the parent process's address space. Therefore, mysql clearing the command-line strings is only effective for some systems.
-
@morbiuswilters said:
3) mysql masks the password in the CLI args anyway so you can't see it even if you wanted to.
Race condition, anyone?
-
@morbiuswilters said:
This is what it boils down to. Guess what, I don't use any passwords on my databases! I use the MySQL root user as well! However, I don't have a problem with security because nobody can connect to my database from outside the network anyway.
This may be well and fine and secure enough. I'm not a security expert, but I do know that my current customer (well, really their parent agency) have requirements for passwords for everything, and to never store an unencrypted password in any config file anywhere. Not really a choice for us.It has always seemed like a defense in depth strategy to me. They may be able to break into some part of the network, but they would still have more work to be able to connect to the database. And part of that is defending against the insider, who is typically the biggest threat. Nothing is perfect, of course, but the physical security specialists I've worked with tend to look at security measures based on several strategies: Deter, Deny, Defeat, Delay. Each has its value, and a good security plan probably encorporates most or all of them.
It would seem to me that adding layers of passwords could add some deny or delay value. Likewise for encrypting the password.
-
Hey speaking of bad security practices..
What would one have to do to assign the server machine a unique ip address that I could access outside of my home network?
Lets say I wanted the front end program to be able to be opened from a computer off my network? All my computers IPs are the same(via ipconfig). Theres really no way for me to connect to the server because the IP points at the router (I think..) I can ping the IP just fine, though.
And really this is a little personal project of mine.. no critical information would be stored (I remember the WTF article about the guy who kept the company's server at his house.. the server went down one night because a party-goer spilled beer on it) . This is a pretty old machine.. a p4, so theres not much risk involved. The main reason for this is I do development and data entry on a different network usually.
thanks for all the help
-
@alehx said:
What would one have to do to assign the server machine a unique ip address that I could access outside of my home network?
Most NAT routers offer the possibility to map one of their ports to some port of the computer in the LAN.
-
@alehx said:
Hey speaking of bad security practices..
What would one have to do to assign the server machine a unique ip address that I could access outside of my home network?
Lets say I wanted the front end program to be able to be opened from a computer off my network? All my computers IPs are the same(via ipconfig). Theres really no way for me to connect to the server because the IP points at the router (I think..) I can ping the IP just fine, though.
And really this is a little personal project of mine.. no critical information would be stored (I remember the WTF article about the guy who kept the company's server at his house.. the server went down one night because a party-goer spilled beer on it) . This is a pretty old machine.. a p4, so theres not much risk involved. The main reason for this is I do development and data entry on a different network usually.
thanks for all the help
Actually there is two ways you can access your home network(specifically your server) externally. Either get your ISP to assign you a static ip address or use a dynamic domain service. Then you can forwards the ports from your router to individual machines/servers (assuming your using a static IP configuration, which I'm 99.99% sure your not). However, from your question, I can tell your understanding of networking/ethernet/ports/IP configuring is minimal at best.So I'm not going to go into any further details as I'm sure you will screw something up and either leave your home network several unsecure or severely useless. Learn all you can about about networking/ethernet/routing before you consider anything. Preferably a minimum level of CCNA Pts 1&2, which would give you a decent understanding of how internal networks work. Obviously CCNA isn't the only good source for learning this but it's the only thing I can think off the top of my head that should give a good understanding of what you should know.
-
So if my router has a virtual server setting.. can I do this:
Incoming port 8081 tcp to address 192.168.0.4 port 3306 ?
And then if I were to try to connect I would use something along the lines of (DNS IP):8081 and I would be routed to port 3306 on the server machine?
-
@alehx said:
So if my router has a virtual server setting.. can I do this:
Incoming port 8081 tcp to address 192.168.0.4 port 3306 ?
And then if I were to try to connect I would use something along the lines of (DNS IP):8081 and I would be routed to port 3306 on the server machine?
Yes, exactly. Look for "port forwarding" in the user interface of your router.
-
The ADO/MySQL Connector worked perfectly (although your link went to the older one. I'm using 5.0)
I did have to add the MySQL library from http://devart.com/mysqlnet/download.html
Everything works well now. The only thing is my router has lists of programs instead of actual inputs so I'm not sure what kind of server MySQL would be considered. (FTP, Web, etc. are all listed types of servers). I wish I could just type it in there.
-
@alehx said:
Everything works well now. The only thing is my router has lists of programs instead of actual inputs so I'm not sure what kind of server MySQL would be considered. (FTP, Web, etc. are all listed types of servers). I wish I could just type it in there.
Unfortunately, your router is probably of the "the user is too stupid to do this" type, so it might not actually let you do the port forwarding on your own.
-
Well according to Hitsuji, this might have saved my life. Who knows what horrible fate awaited me if I tried to change router settings.
Copy Code
