I have a coding project in MS Access. There are some developers coding and checking in the source-code to a SVN-Server.
As a SVN-Server is for managing code, it recognizes changes in the source-code files.
In these source-code-files there is a problem. VBA often changes uppercase and lowercase letters and we have no clue why.
When I do a commit it is i.e
'two examples
Call myfunction(txtNodeID)
rst![Username] = Environ("USERNAME")
Another developer updates his repository and uses my code and it changes to
'two examples
Call myfunction(txtNodeId)
rst![UserName] = Environ("USERNAME")
SVN recognizes this as a change. So we have many changed files although the logic did not change but Access modified uppercase and lowercase.
Does anyone know why Access is acting like this and how to prevent this?
Thank you.
The VBA editor should enforce variable name case to be the same as the declared variable name. This means, you should be unable to write the following:
Dim someID As String
someId = "5"
It does the same with functions. So ENVIRON becomes Environ.
However, this can get weird if you don't enforce variable declaration (no Option Explicit at the top). Then the editor will have a hard time knowing which is the correct case, and tend to change everything to the first occurrence.
The solution is to get all devs to use Option Explicit, so each variable is explicitly declared and the VBA editor knows which is the correct case (and there are many additional advantages). To avoid quirks, they should also make the edited line loses focus before saving (that's when the check happens, so you can do this wrong if you really want to. If you do, it can change to the correct case when touched).
The txtNodeID is changed to txtNodeId, because the latter is declared in the program somehow. Try this piece:
Sub TestMe()
someVariable = 5
End Sub
Then write on another module only Public SOMEVARIABLE. The TestMe sub would look like this now:
Sub TestMe()
SOMEVARIABLE = 5
End Sub
Related
I'm trying to call a Sub from another Form, but I get:
Error 2465: Application defined error or object defined error
I already know that to call a procedure from another form I can use the syntax:
Form(Name).Procedure
But, in this case I want to refer to this form from a variable (Type Form).
Code from form Parametro_Cadastro:
Dim formCaller As Form
Set formCaller = Application.Forms("Cadastro_Aluno").Form
If (Not formCaller Is Nothing) Then
'
formCaller.SetDadosParametroCadastro Me.txtKey.Value, dadoAlterado
Set formCaller = Nothing
End If
Code from form Cadastro_Aluno:
Sub SetDadosParametroCadastro(ByVal KeyValue As String, ByVal DataValue As String)
'
'...
End Sub
The code in Parametro_Cadastro gives Error 2465 on the line:
formCaller.SetDadosParametroCadastro Me.txtKey.Value, dadoAlterado`
...even before the Sub SetDadosParametroCadastroin the form Cadastro_Alunos to be called.
In the Immediate Window, the variable formCaller is already signed as Form\Form_Cadastro_Alunos as expected.
What can I do in this case?
EDIT
The only way it worked was to assign the variable formCaller to Access.Forms(formName) and not through Application.Forms(formName) or simply Forms(formName), so the code now is like below:
Code from form Parametro_Cadastro:
Dim formCaller As Form
Set formCaller = Access.Forms("Cadastro_Aluno")
If (Not formCaller Is Nothing) Then
'
formCaller.SetDadosParametroCadastro Me.txtKey.Value, dadoAlterado
Set formCaller = Nothing
End If
When I check the variable formCaller in the Imediate Window, I also get (as before) Forms\Form_Cadastro_Alunos.
The interesting thing is this only change make the code work as expected. Maybe the Forms member to be called is from Access Object instead of Applications?
Although you can call a procedure from a form, it's generally avoided and is considered bad practice.
Any Sub or Function that need to be shared should be placed in a separate, shared module.
Some excellent advice from Stewart # Bytes.com:
Form code modules are essentially 'private' in scope. Functions and subroutines defined in them are normally unavailable outside of the form concerned - although it is actually possible to call the functions and subroutines defined as Public in scope within a form code module from outside of that module.
Use of the keyword Public is not just a matter of suddenly adding one as a change of style. It reflects that you wish the subroutine, function or variable to be available outside of the scope of the code module concerned...
The code modules which can be created or opened from the Modules tab are the usual locations of public subroutines and functions. Named modules provide a means of grouping tasks by logical function, and if used consistently can be an aid to maintainability.
I use many several named modules in my applications, separating custom linked table maintenance from username parsing, e-mail handling and so on. I also include a "General" module which contains general bespoke functions that I find useful and re-use across multiple databases (for example, to return the current financial year or the current quarter within it).
All subroutines and functions defined using the Public keyword in the publicly-accessible code modules are available outside of the module concerned, whereas those defined as Private cannot be used outside of the scope of the code module in which they reside.
"If you must..."
If, for some reason, you must call a public sub from a form, the syntax is:
Call Forms!FormName.SubName
Note that the sub being called must have the Public keyword specified.
More Information:
MSDN : Understanding Scope and Visibility
Bytes.com : How and where to use Private or Public sub or function?
I am the maintainer (but thankfully not the creator) of a very old, very large and very badly written classic ASP site for an electronics manufacturer.
Security is a joke. This is the only thing done to sanitize input before throwing it into the mouth of MySQL:
Function txtval(data)
txtval = replace(data,"'","'")
txtval = trim(txtval)
End Function
productid = txtval(Request.QueryString("id"))
SQL = "SELECT * FROM products WHERE id = " & productid
Set rs = conn.execute(SQL)
Because of that, the site is unfortunately (but perhaps not surprisingly) victim of SQL injection attacks, some of them succesful.
The simple means taken above is not nearly enough. Nor is using Server.HTMLEncode. Escaping slashes doesn't help either as the attacks are quite sophisticated:
product.asp?id=999999.9+UnIoN+AlL+SeLeCt+0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39,0x393133353134353632342e39,0x393133353134353632352e39,0x393133353134353632362e39
The url above (an arbitrary attempt taken from the access log) gives the folling response from the site:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[MySQL][ODBC 5.3(w) Driver][mysqld-5.1.42-community]
The used SELECT statements have a different number of columns
/product.asp, line 14
This means that the injection made it through but in this case did not succeed in getting any data. Others do, however.
The site consists of hundreds of ASP files with spaghetti code summing up to many thousands of lines without much structure. Because of that it is not an option to go for parameterized queries. The work would be enormous and error prone as well.
One good thing though is that all input parameters in the code are consistently passed through the txtval function, so here is a chance to do it better by augmenting the function. Also, since all SQL calls are done with conn.execute(SQL) it is quite straightforward to search and replace with eg. conn.execute(sanitize(SQL)) so here is a chance to do something about it too.
Given the circumstances, what are my options to prevent or at least minimize the risc of SQL injection?
Any input is much appreciated.
Updates:
1.
I do understand that parameterized queries is the correct way to handle the problem. I use that myself when I create websites. But given the way the site is built and the size of it, it will take 1-2 months to modify, test and debug it. Even if that is what we end up with (which I doubt) I need to do something right now.
2.
The replacement with the html entity is not a typo. It replaces single quote with its html entity. (I didn't make the code!)
3.
In the specific example above, using CInt(id) would solve the problem, but it could be anything, not only numerical inputs.
UPDATE 2:
Ok, I know that I am not asking for the correct solution. I knew that from the start. That's why I wrote "Given the circumstances".
But still, filtering inputs for mysql keywords like select, union etc would at least make it better. Not good, but a little bit better. And this is what I am asking for, ideas to make it a little bit better.
Although I appreciate your comments, telling me that the only good option is to use parameterized queries doesn't really help. Because I know that already :)
I wouldn't give up on parameterized queries. They are the single best tool you can use to protect yourself from SQL Injection. If your plan is to replace all of these calls:
conn.execute(SQL)
to these calls:
conn.execute(sanitize(SQL))
then you're already looking at modifying each interaction with SQL (BTW, don't forget Command.Execute() and Recordset.Open(), which may also be used to run SQL statements). And since you're already planning on changing these calls, consider calling a custom function to run the statement. For example, replace:
set rs = conn.execute(SQL)
with:
set rs = MyExecute(SQL)
and then use your custom function to set up a proper parameterized query using a Command object instead. You'll need to cleverly parse the SQL statement in this custom function. Identify the values in the where clause, determine their type (perhaps you can query the table schema), and add parameters accordingly. But it can be done.
You can also take this opportunity to sanitize the input. Use a RegExp object to quickly strip [^0-9\.] from numeric fields, for example.
But there's still the opportunity that you'll return a recordset from this function that will be used to write values directly to the page without being HTML-encoded first. That's a real concern, especially since it sounds like your site has already been targeted in the past. I wouldn't trust any data coming from your database. The only option I see here (that wouldn't involve touching every page) is to return a "clean", HTML-encoded recordset instead of the default one.
Unfortunately, you're still not out of the woods. XSS attacks can be done via QueryString parameters, cookies, and form controls. How safe are you going to feel after "fixing" the SQL Injection issues knowing that XSS is still a very real possibility?
My advice? Explain to your supervisor the security threats plaguing your site and convince him/her the need for a thorough review or a complete rewrite. It may seem like a lot of resources to throw at an "old, already-working website", but the moment someone defaces your website or truncates your database tables, you'll wish you invested the time.
This attack should only affect numeric values passed in your SQL.
There may or may not be a quick fix depending on whether the same txtval function is used for both numeric and string values (and others like date too).
If txtval is only used for numeric values (probably unlikely) then you could protected by adding single quotes around the value, eg:
Function txtval(data)
txtval = replace(data,"'","'")
txtval = "'" & trim(txtval) & "'"
End Function
If it is used for all value types then your only option might be to search through all the code and either:
1) Add single quotes to all numeric SQL, eg:
SQL = "SELECT * FROM products WHERE id = '" & productid & "'"
2) Create a new function just for sanitizing number values and then change all your queries to use that (not a quick fix), eg:
Function numval(data)
If IsNumeric(data) Then
numvalue = CDbl(data)
Else
numvalue = 0 'or NULL?
End If
End Function
And then change your queries, eg:
productid = numval(Request.QueryString("id"))
SQL = "SELECT * FROM products WHERE id = " & productid
Is there common code (ie. in an include file) that is used to open the database and create the conn variable used in your sample code?
If so, then you could just replace that code and create your own class with Open, Close and Execute functions (at least). You may need other methods too if they are used in your code.
That way you could effectively override the execute in lines like Set rs = conn.execute(SQL).
Eg:
Class MyDatabase
Private m_conn
Public Sub Open(connString)
Set m_conn = Server.CreateObject("ADODB.Connection")
m_conn.Open connString
End Sub
Public Sub Close()
m_conn.Close
Set m_conn = Nothing
End Sub
Public Function Execute(sql)
'Sanitize input here (sql), simple example just for this type of attack
If InStr(sql, "UnIoN AlL SeLeCt") <> 0 Then sql = ""
'return a RecordSet
Set Execute = m_conn.Execute(sql)
End Property
End Class
Then change your common conn declaration from... (eg)
Set conn = Server.CreateObject("ADODB.Connection")
...to...
Set conn = New MyDatabase
If you keep the txtval function I would also update it to escape slashes as well as single quotes, eg:
Function txtval(data)
txtval = Replace(Replace(strValue, "'", "''"), "\", "\\")
txtval = trim(txtval)
End Function
Hopefully something here might be of help.
I am trying to have the file dialog box pop up so the user can select a file path to export a file in VBA but for some reason it throws this error on the following line of code.
Error: Method 'FileDialog' of object '_Application' failed
Code: longResult = Application.FileDialog(msoFileDialogFolderPicker).Show
All Code:
If choice = 6 Then
Dim intResult As Long
Dim strPath As String
'the dialog is displayed to the user
longResult = Application.FileDialog(msoFileDialogFolderPicker).Show
'checks if user has cancled the dialog
If intResult <> 0 Then
'dispaly message box
Call MsgBox(Application.FileDialog(msoFileDialogFolderPicker _
).SelectedItems(1), vbInformation, "Selected Folder")
End If
Else
End
End If
I am really unsure how to fix this issue. I checked my syntax and everything.
I know that this is a bit of an old question at this point, but since it doesn't actually have the answer, and I needed one today, I'm going to chime in with what I found just in case anyone else needs the answer too.
To fix this you need to add a reference to "Microsoft Office [yourversion] Object Library" in Visual Basic Editor >> Tools >> References...
The dialog in question should look like this:
Was trying to do the same thing myself and found this question. I realize that it is over a year old.
Try using the actual number (4) instead of msoFileDialogFolderPicker, that worked for me. I think something needs to be installed for the msoFileDialog constants to be initialized, when I tried printing any of the constants defined in the help file in the immediate window nothing was printed.
Also, why does your code have one variable longResult and one variable intResult?
Almost nothing is an integer in VB6 as integer is a VB4 16 bit type. Win32 Integers are called Long in VB6/VBA.
This was to make porting 16 bit code to 32 bit easy.
Check out http://msdn.microsoft.com/en-us/library/office/ff865217%28v=office.15%29.aspx for more information on proper syntax with FileDialogue.Show method. It appears you need a Set in front of your variable.
If you are after some cool UI, you can checkout my Github for sample database using .NET wrapper dll. Which allows you to simply call a function and to open filedialog with file-drag-and-drop function
Dim FilePaths As String
FilePaths = gDll.DLL.ShowDialogForFile("No multiple files allowed", False)
'Will return a JSONArray string.
'Multiple files can be opend by setting AllowMulti:=true
here what it looks like;
I am hoping someone can help me possibly debug the below code, as I am confused as to why it is happening.
I have a fairly simple VBScript that runs when a user logs onto a server/PC, that will create some signatures based on their active directory details. I have decided to move each section of the signature creation into a function, in order to make things a bit easier when creating new signatures.
Here is the function I am having issues with:
'Function to add job title and company
Function AddTitle
objSelection.Font.Name = "Calibri"
objSelection.Font.Bold = False
objSelection.Font.Italic = False
objSelection.Font.Size = "11"
objSelection.Font.Color = RGB(0,0,0)
If(strTitle) Then
objSelection.TypeText strTitle & Chr(11)
End If
objSelection.TypeText strCompany & Chr (11)
End Function
Now, when calling the function later on using:
'Add job title and company
AddTitle
It ignores the section within the If statement. I know that some variables need to be defined globally for them to work in a function, and strTitle is definitely defined at the beginning of my script.
Am I missing something totally obvious, as the section inside the if statement functions correctly if taken out of the if statement. Likewise, If I were to add the if statement to my script inline, and take it out of the function, it works correctly.
It is only when running from the Function.
Apparently you have a global On Error Resume Next somewhere in your script, which suppresses the "Type Mismatch" error that the line If(strTitle) Then normally would raise.
strTitle probably contains a string value, so you can't use it like a boolean value in a conditional. Change the line to something like this:
If Trim(strTitle) <> "" Then
and your code should work as expected.
I'm using access 2007 and this behaviour can be replicated as follows.
1) Create new access database accdb file.
2) Open database and create new vba module.
3) Create 1st subroutine sub1:
Sub sub1()
Msgbox Err.Description
End Sub
4) Create 2nd subroutine sub2:
Sub sub2(Description as String)
Msgbox Description
End Sub
At this point everything is normal.
5) But if I go and change sub2 so that 'Description' reads 'description', i.e. change 'D' to 'd' like so:
Sub sub2(description as String)
Msgbox description
End Sub
This also has a knock-on effect and changes sub1 too! So that sub1 now reads:
Sub sub1()
Msgbox Err.description
End Sub
Why has 'Err.Description' changed to 'Err.description' ?
This behaviour seems to have no effect on the actual functionality of the code, so no problem there. The big issue I have is that I'm exporting my vba modules as text files and putting them under SVN control. And just recently a whole load of pointless 'changes' have been committed to the repository because of this.
Any ideas on how to stop this from happening?
Sorry. That is a hard-coded "feature" of VBA. See similar question here: How does one restore default case to a variable in VBA (Excel 2010)?
The way I've worked around that with source control is to run my repository through a script that does the following:
Revert all modified files with vba code extensions (creating backup .orig files)
Do a case-insensitive compare of the .orig files to their counterparts
If there are no changes (outside of case changes) delete the .orig file
For the remaining .orig files (the ones with actual changes) delete the counterpart file and remove the .orig extension
What this does is effectively hide files where the only changes are to the case (a constant problem when working with VBA files, as you're experiencing). It does not hide case changes in a file that has had other modifications done to it. It's far from a perfect solution but it's the best I've come up with.
Additionally remember that in VBA, variable names are not case sensitive. So Description and description are the same within the same scope.