So initially, I thought I was doing something wrong as I can't find anyone else trying to do this, but maybe I just do things in a more complicated way. Anyway; I have this line of code:
newtab(listA(i).Split("""))
That, in my mind should work, because why wouldn't you want to split a string by ", right? Well apparently vb.NET doesn't like that.
newtab(listA(i).Split(""""))
You need to use "" for a " within "..."
Try using
newtab(listA(i).Split("\""))
Related
I'm trying to update data in textbox and this error show up. Is it incorrect query?
Try
Dim Str = "UPDATE userinfo SET firstname='" & TextBox1.Text.ToUpper & "',lastname='" & TextBox3.Text.ToUpper & "'," &
"WHERE id='" & Label15.Text
connection.Open()
Dim mysc2 As New MySqlCommand(Str, connection)
mysc2.ExecuteNonQuery()
MsgBox("User successfully updated!", MsgBoxStyle.Information)
connection.Close()
Me.Close()
Catch ex As Exception
MsgBox(ex.Message)
connection.Close()
End Try
As noted, it not only less then ideal to try and concat all those things together, but as you can see it is ALSO really easy to mess up the sql string.
So, your sql looks wrong. It should be this:
Dim Str as string
Str = "UPDATE userinfo SET firstname = '" & TextBox1.Text.ToUpper & "'," & _
"lastname = '" & TextBox3.Text.ToUpper & "'" & _
" WHERE id= " & Label15.Text
Now of course, we don't know if "ID" is a string, or a number type. And if it is a number, then you do NOT surround the Lable15.Text value with single quotes. And you had a extra "," after the list textbox 3 in your sql.
But, as noted, the suggestion here is to use parameters. While this is a bit wee extra code, such code is LESS prone to concatenation errors, is easier to read, and in fact easier to write. (you can hit ctrl-d in the code editor to duplicate the line you are on!!!).
and of course, using parameters ALSO gives you AUTOMATIC data typing. So you don't have to worry or think about those extra parameters. And not only do numbers have no single quotes around them, date delimiters can even be more of a challenge.
Along without the messy concatenation?
Along without the data type issue (quotes or not????)
We ALSO get protection from SQL injection.
So, we getting a real nice truckload of bonus features. I have ALWAYS lamented that many suggest to use parameters, but then don't point out the benefits (beyond that of sql injection).
So you might wind up with a extra line or two of code, but that code is LESS error prone, and in most cases will be easier to read, but ALSO MUCH more able to allow you to add more parameters - all without messy string concatenations.
So, our code can be this:
Dim Str As String
Str = "UPDATE userinfo SET firstname = #firstName, lastname = #lastname WHERE id = #id"
Using cmdSQL As New MySqlCommand(Str, connection)
cmdSQL.Parameters.Add("#firstname", SqlDbType.NVarChar).Value = TextBox1.Text
cmdSQL.Parameters.Add("#lastname", SqlDbType.NVarChar).Value = TextBox3.Text
cmdSQL.Parameters.Add("#id", SqlDbType.Int).Value = Label15.Text
cmdSQL.Connection.Open()
cmdSQL.ExecuteNonQuery()
End Using
Some interesting things to note:
First: it really nice to read, right?
Second: Easy to code.
When I typed in this:
cmdSQL.Parameters.Add("#firstname", SqlDbType.NVarChar).Value = TextBox1.Text
While on above, I hit ctrl-d two times. that duplicated the above line.
So now, I just "cursor" up/down into the parameter value area almost like editing a column in Excel. (I did not HAVE to type those extra lines - but just edit the values and change the textbox/label values.
And BETTER is while typing in that code, I can EASY see, and read, view the nice sql line right above in code - so I just read off the parameters as I type, and edit the two additonal parameters rows. So, in fact, I actually wind up typing LESS then your posted code. And with the nice sql text in view - I have a LOWER brain work load - I don't have to remember the parameters - I just read them!
Next up:
SQL server does not care about upper vs lower case - so you don't need to worry about upper and lower - they will match regardless.
More next up:
By wrapping the whole deal inside of a using, then we don't have to close the connection - this is correctly handled by the using block (it cleans up for you).
More more next up:
And because we don't use string concatenation for the values, and DO NOT have to worry about quotes or not, and also get sql injection protection?
We ALSO get STRONG data typing.
In other words, the values from the controls are CAST to the correct data types required by sql server. I mean, often you can munge in a number with quotes as a string - sql server might work, might not! - but this way, automatic taking care of the quotes (or no quotes for numbers) is done for you!
so the updated original sql string should work, but give the parameters a try, and while the using block is a extra line of code, we don't have to close the connection, so we get back that 1 line of code!
The major goal here is it not that you must do this, or do that! Often when starting out, such advice is not all that helpful. Saying don't do that? Geesh - what kind of help is that.
In above, I not only said to use parameters, but I ALSO made a long and impassioned case as to why they are better.
The strong data typing is really nice, and protection from SQL injection is in fact a bonus feature here!
The real gold here is that we wound up with not a lot of code, and code that is easier to maintain, easier to read, and even MORE so if we decide in the future to add some more text boxes etc. on the form.
I mean, lets say you have 4 or 5 text boxes. Can you imagine then how absolute difficult that long huge concatenated string will be to edit, look at, and more so try to debug errors!
So must you use parameters? no, you don't have to, but once you try the above?
You adopt the above because the code is less mental effort and work on your part - and that's really what great code is all about.
I not that great of a coder, and thus your long string sql is too hard for me, and too great of a effort. Only those really good coders can figure out that mess. For me, you have to think as me as a one cell creature - limited brain power. The same goes for great pool players. They actually don't make the hard and difficult shots - they set themselves up in such a way that they never have to make those hard shots, or in this case read and maintain difficult and complex code.
Your code can work - but it is beyond my pay grade and ability to read and maintain such code!
Good luck!
Im using the FolderBrowserDialog to pick a path.
It will return for ex. this= C:\Mypath1\Mypath2\DOCS
I would like to remove everything but DOCS.
If i use VBA i would use a InStrRev combined with a left. But now in in VB.net and im not sure how to achieve this, im pretty sure there is something better than my old VBA way?
Anyone there that could help, google failed me.
Try this:
IO.Path.GetFileName("C:\Mypath1\Mypath2\DOCS")
Which returns DOCS.
I am not sure what you want to do. But maybe this can help you get the last part of a string
Dim fullPath As String = " C:\Mypath1\Mypath2\DOCS"
Dim Parts As String() = fullPath.Split("\")
Dim lastPart As String = Parts(Parts.Length - 1)
This may be a simple question, but I have searched quite a few sites and have tried a few of my own ideas and I still cannot seem to find a simple way to get Visual Studio to replace all of the listbox items with the string of nothing with some other text.
Using things such as :
For Each S In ListBox1.Items
S.Replace("", "Not Blank")
Next
Shows:
Error
String cannot be of zero length
Which is quite annoying because the actual listbox item contains no text.
This seems to be one of the easiest things I have ever encountered while using vb.net. But it now seems very hard for what should be a simple command.
A couple of problems. The Replace function returns a new value, and you promptly ignore it. Second, you can't really modify the collection as you For-Each over it, so a For-Loop would be more appropriate.
I think you want something like this instead:
For i As Integer = 0 To ListBox1.Items.Count - 1
If String.IsNullOrEmpty(ListBox1.Items(i).ToString) Then
ListBox1.Items(i) = "Not Blank"
End If
Next
I have a method which looks like this
def full
"#{self.first} #{self.second}"
end
problem is that I want to escape it, so to do it in the model I do
def full
ERB::Util.h("#{self.first} #{self.second}")
end
but if first or second have & in it, it would give me & instead of &
also if they have apostrphies ' it would escape them and make it unreadable..
Is there a way to avoid XSS and make the string readable as well?
I think you can use this html_escape Click here...
If I have a string like input = "AA["
If Right(input, 1) = "[" Then Do stuff
The If statement returns false, even if I try converting things around to chars, etc etc. But if I do this is returns true:
Dim temp As String = Right(input, 1)
If temp = "[" Then Do Stuff
I like knowing little semantics like this, any idea why it comes out this way?
Or don't use Right at all since this is .Net
Dim s As String = "AAAAAAA]"
If s.Substring(s.Length - 1, 1) = "]" Then
Stop
End If
'or
If s(s.Length - 1) = "]" Then
Stop
End If
I've seen weird behavior like that when debugging.
In fact, today I had something simlar
Dim records As Integer
records = If(o.dr Is Nothing, o.ADO.rs.RecordCount, o.ADO.DS.Tables("tbl").Rows.Count)
That should work, using the rs.RecordCount when dr is nothing, otherwise using the Rows.Count. It didn't, records was ending up as zero. Rewrote it as a full if then/else block and it works.
It's never my first thought that the compiler/debugger/ide is messing things up, but you should keep it in the back of your mind for consideration: the programmers that wrote those programs are just as human and fallible as you or me.
It shouldn't. Are you sure you didn't have a typo? The result of RIGHT is a string, and if the input was truly "AA[" the IF will have passed.
I've never had VB act wonky on something like this.
If the code appears in a form, then the .Right property of the form overrides the string manipulation function. You need to specify the parent namespace - e.g. VisualBasic.Right - to ensure that you get the correct method.
I think you may have some kind of strange overload confusion occuring here.
You are specifiing "Right" (which could be calling a local "Right" function).
The function your implying is "Microsoft.VisualBasic.Strings.Right" in most of my code ends up being "Strings.Right" due to the global import.
I would try changing you code to the below and see if it still happens, in order to rule out some overload/scope confusion. (and/or the reduced "Strings.Right")
If Micosoft.VisualBasic.Strings.Right(input, 1) = "[" Then Do stuff