Row source for combo boxes and control sources for sub forms require a string. As long as the table being queried by this string is part of the database..things work fine.
But I am trying to query the values for the combos from a table in a different database.
Row source does not accept anything other than a string. How do I set it??
Also my subform points to a table in a different database.. here the object source will also accept nothing but a string.. How do I link it?? (Provide links to examples if possible.)
You can link the tables from the other database, use the IN keyword or use ADO recordsets.
SELECT id, atext FROM table1 IN 'z:\docs\test.accdb'
To link, see http://office.microsoft.com/en-us/access-help/import-or-link-to-data-in-another-access-database-HA001227658.aspx?CTT=1#BM3
Related
We have a legacy vb6 solution working with an access database with one of the forms containing a number of mutually exclusive option buttons
There is no reference table and the options are saved/loaded using hard coding ie. values in the field optState would be either 0, 1 or 2.
We are building a query in Access to export data into XML and looking for a way to convert the options into text fields without updating the DB or VB application!. So if 0 show some text, 1 some other text ... etc.
Is there a way we can do this in the access query or access sql?
No plans to upgrade the VB or DB so looking for a workaround.
thanks
jay
You could use IIf (Immediate If) to do this in a query. As you have multiple values per field, you would need to nest them. Something like:
SELECT tblStatus.*,
IIf([Status]=0,"Available",IIf([Status]=1,"Sold",IIf([Status]=2,"Withdrawn",""))) AS StatusOut
FROM tblStatus;
This returns an empty string if a value is not 0/1/2. Or you could use Switch in the query:
SELECT tblStatus.*,
Switch([Status]=0,"Available",[Status]=1,"Sold",[Status]=2,"Withdrawn") AS StatusOut
FROM tblStatus;
Regards,
I am having to redevelop an MS Access 2003/2010 ADP project, that uses SQL Server views as the RecordSource for all its forms, into an MS Access 2016 ACCDB.
I have tried using pass through queries to get the data and this works fine for readonly columns, however when I want to change the value in one of the bound columns, it says that the RecordSet is not updateable, which is what you might expect if using a view.
But I have now read that if you define the view with SCHEMABINDING like this:
ALTER VIEW [dbo].[vwQuote_MinibusesDetails]
WITH SCHEMABINDING
AS
SELECT ...
and add a UNIQUE CLUSTERED INDEX like this:
CREATE UNIQUE CLUSTERED INDEX CIX_vwQuote_MinibusesDetails
ON vwQuote_MinibusesDetails (txtQuoteNo, txtVersion, txtVehicleNo);
and then add the view to your project as a DSN-less TableDef like this
stConnect = "ODBC;Driver=SQL Server;Server=" & SERVER_NAME & ";Database=" & APP_DATABASE & ";Trusted_Connection=Yes"
Set td = CurrentDb.CreateTableDef(stLocalTableName, dbAttachSavePWD, stRemoteTableName, stConnect)
CurrentDb.TableDefs.Append td
it becomes editable as if it were a table.
However, when I open the TableDef in Access it shows all the rows and columns as if it were editable, but if I try to edit a column, it says that there is a Write Conflict with another user's changes, when I am 100% sure that there isn't because I am the only person using it.
Any ideas? (I am using Access 2010 at the moment)
But why do all that truckloads of work? There is zero reason to do all that extra work.
Simply bind and set the forms data source to a view. It is assumed that you will simply link all of the existing views on the client side. Access will thus see all the views as simply tables, and views (as opposed to Pass through queries) are read/write.
So, there is no need to:
Have ANY connection strings in your code. If you ARE using connection strings in code, then you approach is all wrong. Just link to the views, and set the forms data source as that view.
At this point, the forms can edit data.
As for a pass-through quires to drive combo boxes? Do NOT do this. While a PT query is likely the fastest way to pull data, the access client cannot filter PT queries. So you ONLY EVER want to use a PT query for cases in which the client side does NOT have to filter the results. If you bind a combo box to a PT query, then Access needs and wants to ONLY pull the one value from that table for display. And since the access client can’t filter a PT query, then it will scan the WHOLE data source for that combo box to get the one value that is currently displayed. If you use a linked table (or even a view) to that source that drives the combo box, then the access client can filter that dataset to the ONE row. So, do NOT use a PT query for ANY case in which client side filtering is required. A linked view (or linked table) is fine in these cases.
So, just bind the forms directly to the linked table, or the linked view.
If the table has 1 million rows of data, and you say do this:
Docmd.OpenForm "frmInvoice",,,"InvoiceNum = 1234"
Access will open the form to the ONE row of data, and ONLY pull one row down the network pipe. This is despite that the form in question is bound to a table of 1 million rows. The form will load instant, and you not had to write any sql, any connection stuff, and not really do anything different then how you developed typical access applications.
Bound forms are how and why Access saves huge development dollars. If you jump to .net, then you have all kinds of tools and wizards that can help you around this issue. So in .net, you could adopt the dataset designer, or use the newer entity framework.
In Access, we don’t have this huge tool box of data designers and tools, so if you attempt to hand code, and code up the data sources for a form, then you get the worst possible outcome (you write truckloads of code, and don’t have all those cool tools for un-bound forms).
Simply link your forms to linked tables (or views) and you now have a working data bound form without any code. If you need to load the form, then use the 20+ year standard approach of the “where” clause of the open form command to open the form to the one record. The access client will ONLY pull what you put in the “where” clause.
So, to wire up a form for editing of data, ZERO code is required. The only developer efforts will then to ensure that the form does not pull un-necessary data to the client.
I have to figure out from what source the value of the field is coming from.
I have tried to search by name txtRun and by Control source name Run in vb classes, but there are nothing matched values.
Are there any ways to do that?
Quite simple:
If the control source is run, the value comes from the column run of the form's record source. The record source can either be a table or a query.
I have an Access 2007 data entry form that is bound to a table that is used solely as a holding station for the data until it is reviewed and appended to the permanent tables. There are several fields in the table (and thus form) that have multi-value selections (derived from a look-up table query). The user does not care if the data is searchable so storing in the text field as a long list is fine. The problem is with appending. I cannot append multi-value lists to a table.
I noticed that if I save the table as an excel spreadsheet and then import it back into a table with the same database structure as the exporting table but without multi-value combo boxes for those fields requiring multi-values (they are now just text boxes) that the list is there and formatted the way I want.
So I am thinking, what code is Access using to export the correct values to Excel and could I just use similar coding to append to the permanent tables (which don’t have to have the corresponding text fields formatted as a multi-value list) instead of having to export to an Excel file and then import this back into a new template? Please note that although some of the lists are only 10-15 options, one list has over 50 possible selections to choose from.
I am just trying to make a user friendly data entry interface without scores of vba coding (which I am a newbie at). Alternate ideas are welcome.
Internally, Access is doing just what Allen Browne's ConcatRelated function does. Fortunately, Allen's code will handle multi-valued fields so you can just use it in a query like this
INSERT INTO MainTable ( MealType, Meats )
SELECT MealType, ConcatRelated("Meats","TempTable","TempID=" & [TempID]) AS Expr1
FROM TempTable;
where [MainTable].[Meats] is Text(255) and [TempTable].[Meats] is a multi-valued Lookup field.
I have an access database and I want to export fields from ONE highlighted row to a word document and email it to a recepient.
From the Access database I want to export the following fields:
Initials (character string), HospNo (Character and Number string), date, comment (character string)
and I want to export these fields from the row of my choice to a word document, c:\test.docx, with 4 MERGEFIELD's bookmarked as Inits, HosNumber, ScanDate, Diagnosis, respectively.
I think MailMerge is the solution and that's why I used Mergefileds in Word. But I know very little VBA and don't know where to start from.
I have Office 2010 on my PC.
Is that information sufficient to explain the problem?
From a very high level, you're probably going to need to create a recordset in VBA that contains just the one record you want to export. You can then use that recordset as your source for your mailmerge.
I've never done mailmerges, but this should get you started:
Dim db as Database
Dim rec as Recordset
Set db = CurrentDB
Set rec = db.OpenRecordset("SELECT Initials, HospNo, [date], comment FROM MyTableName WHERE SomeFilterCriteria")
'Mailmerge based on "rec"
Obviously you need to change MyTableName and MyFilterCriteria based on your specific info, you didn't give us the table name or how you want to determine which record of data to mailmerge.
Either that or you can build a query, set up the mailmerge from the query, and then put filters in the query that point to your form. In the Criteria line in a query (if you open it in Design View), you would put something like
[Forms]![MyFormName].[MyFieldName]
Also, if you have the ability to do so, change your date field name. The word "date" is a reserved word, which means you have to enclose it in brackets so Access doesn't think it's a built-in command. Change the field name to scandate or something to avoid future problems.
If you are already working with MailMerge, you can just select the line in Access and use the Word Merge feature under the external data link.
If you are looking for a more automated procedure, I believe you will need to use code.