I'm in the process of converting a MS Access 2000 database to MySQL, while still using Access for the front end.
I've come across a problem where some forms get the data from fields in MS Access tables. IE, the "Control Source" value is set to a specific field, and when the form is run, its creates the required number of Textboxes to match the number of entries in the table and populates them with the data from the tables.
Now I'd like to be able to set the Control Source of the Textbox to call a VBA function, which get's the data from MySQL, and populates the textbox with the entries in MySQL table. I'm not sure how this is achieved, or if its even possible.
So could I just create a VBA function and set it in the Control Source property for the Textbox, or do I need a more complicated solution ?
You do not need any code for the text boxes to display. Simply use a linked table to MySql, and the form should function as before. There is little if any reason I can think of here to dump the use of bound forms and bound controls.
Related
I have a SQL Server that is ODBC into my Access which is being utilized as my front end. I created a column in SQL with a BIT data type and created a checkbox with the yes/no data type that uses my SQL Column as its control source. When I go into my form and try to change anything in there and update my tables, I get a writing error and it wont let me append the updates I'm trying to make. As soon as I delete the bit data type, and the check box, then I am able to again append information to my form. Does anyone know a solution or a way I could utilize the Boolean check boxes to report to my SQL Database so that I could track progress of an order, but still be able to append my records? Also if anyone knows why this is happening I would appreciate the information just for my own notes and understanding.
this image shows the column created in SQL Server
This image shows what it looks like in the ODBC table in Access
This image shows the control source I picked which is from a query that utilizes the names of the form comboboxes, text boxes, and hopefully check boxes
This is image shows what happens after I try to update and and close
Thanks
haven't done this for a long time, but the problem could be related to the numbers that are stored. yes/no in access = -1/0, in sqlsrvr = 1/0 (or similar). you could use an INT field in sqlsrvr which will then store whatever access sends (-1 or 0), or keep the BIT but don't use yes/no in access - create a custom yes/no table where yes=1 and no=0 (or whatever BIT needs) and use the custom table as a lookup table for that field which, when updated will send the appropriate value. hope that's all relevant and makes sense.
So I have been messing around with this and after a few other problems running through SQL, Cabinet Vision (our drafting software with a ancient access database) and crystal reports I came to realize that Access cannot accept null values.
So in my SQL Bit data type column I set the default value as 0 and didn't allow nulls. now it records all my check boxes as true or false. and I no longer have a write conflict.
This most commonly arises when a db is developed in Access and at some later date the tables are exported via ODBC to SQLServer. The Checkbox controls on the Access forms were probably placed there using the 'Available Fields' button on the Access 'Design' ribbon. Before getting into complicated solutions with T-SQL modifications to metadata etc, try simply deleting the checkbox control from the problem Access form. Insert an unbound checkbox to replace it, then use the the Properties dialog to set the relevant SQLServer field as the control source for that checkbox. Usually works.
For a client I have to use MS Access 2007 as a lightweight front-end to SQL Server 2008.
One of the requirements, security-wise, is that I need to fetch my recordset data via stored procedures. I'm doing this via SQLOLEDB, based on tutorials provided here: http://accessexperts.com/blog/2011/07/29/sql-server-stored-procedure-guide-for-microsoft-access-part-1/
I have a mainform with some general data, on which I also set the form recordset (Me.recordset) in the code-behind. At the bottom of the form, there is a subform, with a table of rows of data. This is also an ADO recordset being set in the code. In order to make those subform records editable, I made a extra recordset in which I cloned the data in, then I bound it to the subform's recordset (Me.recordset -> but in context subform). I added a save button after each row in the subform, and via an event I'm doing the writes manually via another stored procedure.
This all works, but I get some very weird behavior when I edit some data in the first row (for example), and then click on a field in another row (for example the second row). Now suddenly all my fields change to '#Name?'; basically my subform gets unbound.
Now I'm not sure how to debug this, let stand fix it. Any help on this error is greatly appreciated.
I forget to put tempRs.ActiveConnection = Nothing
It is working as intended now :)
I have an Access 2003 database which uses a main form with a datasheet in a subform. The main form allows the user to select from a menu which updates the recordsource of the subform. The subform also updates the number and type of fields available for editing based on the number and types of fields in the form's recordsource. It's basically a dynamic datasheet generator. This works just fine in Access 2003 and has been for years. If I open the same database in Access 2007 (full or runtime), most of the menu selections work. However, if I choose any menu option that references one particular table, the subform shows column headers, but does not show any rows of data or display any errors. It's as if the query is returning zero rows. Why would there be a difference in Access 2007? Did they add new reserved words?
Things I've tried:
Updated every field in the table to ensure there are no null values (no change)
Renamed every field and the table name just in case there are new reserved words (no change)
Compacted and repaired the front end and back end (no change)
Tried including and excluding fields one by one to see if anything changed (no change)
Put the form's recordsource in a new query. (it returned the expected number of rows)
Checked to make sure the form is not set to data entry mode. (It's not)
Checked to ensure that no filters were being applied in code. (none were)
Checked to make sure the query is updateable in Access 2007. (It is)
Selectively deleted chunks of data from the source table. (no change)
I'm stumped.
I was able to finally resolve the issue. As I noted above, my datasheet is a subform. The parent form sets the options that determine how the subform will be built. While the datasheet is being built, the subform's sourceobject is replaced with a blank form to hide the prior datasheet and present a smooth transition to the new datasheet. It works beautifully in Access 2000/2003.
When the blank form is replaced with the new datasheet in Access 2007, I found that Access is automatically assigning the primary key of the subform data to the LinkMasterFields and LinkChildFields properties of the unbound parent form. Those properties had previously been blank, and I never set them in code. Perhaps this is as an attempt by Access 2007 to be helpful rather than a bug, but the behavior difference is not noted in any tech reference I can find, including the built-in help file. Since the parent form is unbound, it has the effect of filtering out all of my subform records. If I explicitly set LinkMasterFields="" and LinkMChildFields="" during the form substitution step, everything works as it did before. Hooray!
Again, the solution is that when setting the sourceobject of a subform, be sure to explicitly set the linkmastfields and linkchildfields properties to prevent Access from doing it for you. I hope this saves someone the hours of frustration I experienced.
i am new to access and i am debugging someone's database
how do i know if i am using ADO?
i have stuff in a listbox, how do i use the .GetRows method to put the recordset into a two-dimensional array?
Do you have a reference to the ADO libraries (In a code window, under Tools->References: Microsoft ADO Ext x.x For DLL and Security, Microsoft ActiveX Data Objects x.x Library) Have you set the recordset to an ADO recordset?
You will find details of GetRows here: http://www.w3schools.com/ado/met_rs_getrows.asp
You can use it like GetString, as illustrated in a reply to your previous post.
EDIT
You do not have to have a reference to the ADO libraries to use ADO, but it can be easier. To use ADO without the libraries (late binding), try something like:
Dim cn As Object
Dim rs As Object
Set cn=CreateObject("ADODB.Connection")
Set rs=CreateObject("ADODB.Recordset")
cn.Open strConnect ''Any suitable connection string
rs.Open strSQL, cn ''Any suitable SQL string
As others mentioned, to check if the using ADO, you as a general rate ruled can look in your code. However what's probably confusing you and not has been explained is that it's ONLY in your coding practices do you choose ADO or DAO.
For the rest of the application (ie: BUILT IN OBJECTS) you will use the concept of what's called linked tables. These linked tables handle all of the connection strings and all of the internal workings for you. There's no additional effort required on the user's part when they're developing the application. For all of these internal objects, you don't choose a particular data object type (ADO or DAO).
What this means is that for filling data into forms, data into reports, data into listbox, data into combox boxes etc. you DO NOT write code, and YOU DO NOT use connection strings. And you DO NOT HAVE a choice of ADO or DAO. What this means is that when you look at a combo box or list box or form, you'll get off the confused really fast if you start looking for some type of connection string or asking if that combo box is based on ADO or DAO (hint: you as a genera rule don't have a choice in this matter: all of these object and how they work are handled automatically for you internally inside of a MS access). What this means is all you have to do supply the given object with some SQL, and you're done.
So, all of these objects will as a rule work from your linked tables in access. Once these linked tables are set up, then you build forms, or reports, or list box is based on these linked tables. As a result a as mentioned, you'll not be choosing ( or even have to bother) with DAO or ADO when working with these objects.
The choice of ADO or DAO We'll generally only come into play in your actual code that opens a record set or query directly. Most of the code in a form can be based on referencing the controls or objects such as an combo box that exist on that form. Once again the choice of ADO or DAO it not relevant, and you don't have control over that aspect.
For example, if you wanted to use code to setup the values for a combo box, you would use the following code: (we assume the combo box is a two column combo box, 1st column is id (hidden) and 2nd column company name.
The VBA code to fill or setup the combo box via sql is:
Me.Mycombobox.RowSource = "select id, CompnayName from tblCustomers"
That is it!
Notice how there's no connection strings, no record sets, you just shoved some clean SQL right into the combo box row source and away you go.
Now of course the above assumes you have a linked table called "tblCustomers". You can see/view those tables in the tables tab.
( By the way our combo boxes and listbox is allow more than two columns, to hide columns you set the format lengthy equal to zero for that column. That way you can still access the data in your code, but not have that column displayed in the list box).
So the choice of ADO/ADO is often not an issue. Note that even when you do choose ADO or DAO in your code, you as a general rule should use the built in table objects and this again will not have to bother with an connection string built in code. There are some exceptions here, but let's keep this general for the time being.
The above should clear up a lot of your questions about how come you can't see or tell how the form is using DAO or ADO ( the answer is you don't bother with this, and the answers you don't have a choice, and the answer is this is all automatically handled internally for you by MS access)
2.i have stuff in a listbox, how do i use the .GetRows method to put the recordset into a two-dimensional array?
For what reason do you want to do the above? There is VERY little reason to pull data from a listbox into a array. You have the list box ALREADY loaded up with data, so why then waste time loading this data into an array? For what reason would you do this?
You can reference the data in that listbox, but you might want explain what you're trying to accomplish here. There's no need to pull the data out of the listbox, but you can use code in a form to look at value(s) selected in the listbox, and do a useful things with those selections made. Again, to work with the selected data from that listbox, you don't need an array, you don't need connection strings, and you don't need to write a whole bunch of code to repeat what is our data currying and is available inside of that form (hint: the data inside of that list box is available for you as a collection).
So you don't need a record set, you don't need to write a whole bunch of code nor do you need some connection strings. And you don't need nor want to pull that data from that list box into an array, it's simply not required and is completely overkill. Simply stay what you're trying to do with that listbox, and we'll come up with a solution that's likely only a couple of lines of code.
As mentioned, look at that data tab of a listbox, and take a look at the SQL used to fill that listbox. Does that sql run correctly, and furthermore check of the number of columns specified in the listbox matches the number of columns you have in your SQL that set for that list box in the data tab. Funny things can happen if the number of columns don't match the settings for the number of columns in the listbox.
I have several forms linked tables via queries. The form pull data such as sales and ratios by selecting a product from the main's form's combo box.
I am however having to issues:
1- I would ultimately prefer the combo box to be a free entry; however by just entering in the box and hitting enter (not a button called “enter on a screen” which would initiate recalcs, just normal enter), while it does bring the new information in sub-forms it also changes the information in the original table. If I make the table read only that it just doesn't allow the form to work by saying that the table is read only.
2- The same Read only issue occurs when another user with read only rights tries to use the database.
I understand that ready only is functioning as intended, however I am wondering if there is way to make some functions work while disallowing the updating.
I am unfortunately learning on the go, so go easy plz.
Thank you
You need to make your combo box no linked to the underlying data, but once the data is changed, set/reset the value of the combo box. This way, if some types in a new value
A) it will not update the data whether it is updatable or not.
B) you can still have the subforms update based on this value
Private Sub Form_Current()
cmbMyDisplayOnlyComboBox = Me!WhatEverFieldHasTheValue
End Sub
Again, cmbMyDisplayOnlyComboBox Control Source is blank. Substitute the field that 'use' to be the Control Source as WhatEverFieldHasTheValue