I have a handful of fields linked to a subform (in datasheet view) on my mainform and I would like to be able to edit the data in the table from the fields since the subform is very wide and hard to see all of it. The subform is pulling data through a query to put multiple tables together and I think that's what's preventing me from editing the data from the fields based on what I've seen. The SQL statement that links the fields to the subform is like the following for several fields:=[SubformX].[Form]![Data] I was wondering if some kind of VBA/Query would be able to directly populate the fields based on the subform selection and still allow it to be edited or if there is a simple fix for this problem.
Due to natural limitations on updating data from a form, it seems this approach is not workable without using VBA to stage the update and display. Refer to the comments above for some detail.
Related
My data is being taken from Excel Tables and a messy Access Database.
I have cleaned up the data using PowerQuery in Excel. As such the information going into the creation of a new functional database in Access 2016. Currently have ID numbers linking the various tables together already in excel and I would like these linkages to carry over to excel to help with the design of queries and forms to ensure their functionality.
What I need is a method to add autonumbers/ID numbers to the various tables AFTER the initial data is uploaded.
Therefore the numbers need to continue from last number in each associated table, when new information is added.
Is there a way to set the database to do this to automatically?
I tried to set the ID field to AutoNumber, but it overwrites the original ID numbers which means none of the tables will properly link to each other.
I have tried to set the field to autonumber AFTER adding the information, but the system won't allow that.
I am assuming I will be stuck using VBA and forms to do this, but I honestly don't know how. It seems that no one has ever asked this question before as my google search keeps coming up empty.
Please note, management wants an Access Database, so no I cannot keep it in Excel.
Thanks for any help you can provide.
I'm new to Access and am having trouble finding a solution to this.
I have a FORM as a UI and need to make it easy to navigate to related records within the same form. Basically, if this record is related to that record I want to show it in a field and have the user go to that record by clicking on the field. The related records' IDs do not need to be stored in the underlying table, but they can be if needed. (Only one form and one table is involved.)
Thanks in advance for the help!
I am trying to understand a couple concepts with ADO.net and access. I understand how to query a table or set a record using ADO, and I have looked at various online articles pertaining to pulling tables and handling queries. I am wondering what the relationship is between VBA Forms, DataSheets and Tables.
Am I to understand that a UserForm can contains a DataSheet? And is that essentially a table but seperate? Changing from "Form View" to "DataSheet View" shows me the information being logged in the form. Yet, sorting the navigation view by "TABLE" will not bring up the same information as is logged into the DataSheet.
How would ADO access information from within a DataSheet object and not necessarily a table? Thanks for any advice.
A datasheet is a form. You can remove the Record Source altogether, you will still have a form. It is not uncommon to set the recordsource property of a form at runtime.
Access can work very well indeed in a number of situations. Do not be put off by bad press. The only reason to change is that the current set-up is not working -- because it has grown too big, because the company has grown too big, etc. Even some of these cases can be dealt with by keeping the (working) front-end and replacing the back-end (database) with something more robust. For the most part, problems with Access are not do do with the front-end but to do with the small-office sized database that is Jet/ACE.
I'm working on an ASP.NET 4.0 site, which I inherited ownership of.
It has a number of existing LINQ datasources pointing to individual tables. For example, to the Patient Encounter Summary table in SQL Server.
The problem is in displaying the data there. It's a normalized database, so that table contains (for example) the provider ID, rather than the provider name.
It's simple enough to join the Patient Counter Summary to the Providers table (in SQL)... but how does one do that in ASP.NET? I'm not sure of the correct nomenclature, but the 'mid layer' is VB.
So, the existing LinqDataSource entries are all to individual tables. I tried building a view in SQL Server to do all the joins, but the LinqDataSource doesn't 'see' such views as an option... even if it's read-only (no update, delete, or insert).
Please pardon my ignorance, but it looks like it should be so simple. For example, I have things like <asp:Label ID="Label12" runat="server" Text='<%# Bind("AttendingPhysicianID") %>'></asp:Label>... that it appears to me would be so simple if the LINQ DataSource was a view that joined the tables so I could change it to PhysicianName coming from the Physicians table.
Any guidance would be most appreciated... ideally at the level of 'this guy doesn't know anything'. :-) That is, I've seen all sorts of what looks like VB code on answers to similar questions, but don't know how to implement that within this structure.
Thanks much.
I would recomment to bookmark 101 LINQ samples, it is quite helpful.
Here is answer to your question: http://msdn.microsoft.com/en-us/vstudio/bb737909
Although this question is to do with LinqToSql joins, you state you are attempting to do this because you couldn't expose a pre-written SQL View via the Linq DataSource.
If there is value in using the SQL View you've written, and in having that view accessible outside your VB libaries, I would suggest going the first route and getting the LinqDataSource to expose your SQL View.
Try looking here:
http://msdn.microsoft.com/en-us/library/bb384396.aspx
You're using a System.Web.UI.WebControls.LinqDataSource. Imo, this is a control that lets you use strings to opaquely interact with (what was) a compiler verified query generation technology.
Here's a link to the documentation.
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.linqdatasource.aspx
Here's some relevant passages:
Select - Gets or sets the properties and calculated values that are included in the retrieved data.
The LinqDataSource control enables you to use LINQ in an ASP.NET Web page by setting properties in markup text. The LinqDataSource control uses LINQ to SQL to automatically generate the data commands.
When you are querying a database... You then set the ContextTypeName property to the class that represents the database and set the TableName property to the property that represents the database table.
5.Select (specify which fields or properties to return).
However, if you set the Select property, it means that automatic update, insert, and delete operations cannot be enabled.
So I would think you could include a subquery in the select property to convert an Order.CustomerId into a Customer.Name
But if I were in your shoes, I would abandon the LinqDataSource and just write LinqToSql compiler verified queries.
I have a fully functional DB developed in Access. It was done using a very "interactive" developer-client increment-iterative process as no one really knows what the final DB is to show. All tables were developed (and normalized) as well as forms (and sub-forms), however, now reports must be designed and implemented.
The forms of course, are based on queries which take the criteria from the form itself to run the queries and show information in the subforms. Now, as in practice, the reports have to basically be pretty printable versions of the on-screen forms for distribution. From my research, the reports are also based on queries, but since the queries I have are using the fields from the forms to display the relevant information in subforms, I don't see anyway to create these reports unless I basically duplicate all my queries to not pull values from forms. This seems very tedious and inefficient. Is this the "best practice" way to create reports for a database?
V.K.
You can put a button on the form which launches the report using the same query. The report query will then use the fiels/query from the form, and should then return the same result set.
Hard-coding form fields in a query is the problematic part here -- that's definitely not "best practice". I guess you need these values in your WHERE clause? What you could do is to remove the field references from your queries (so that the query returns all records). In the Subform or Report, don't use the query directly as the record source. Instead, use some SQL that accesses your (generalized) query and and additional filter criteria. For example, the record source of your subform could be
SELECT * FROM myQuery WHERE someQueryField = Me.Parent!SomeFormField
allowing you to use the same myQuery with a different WHERE clause (which does not reference a Form) in your report.
I'm not sure I'm understanding your question, but having recently worked with an app that used a form to drive a report, I might have an inkling.
You don't want your report tied to the single record of the form. You want your report to use the same recordsource as the form, insofar as they are displaying the same data, of course.
The reason for this is that if you hardwire your report to the form fields, the report can't be used except when the form is open, and it can't display anything but one record.
If you create your report so it loads all records, then you'll need to be able to print one record at a time, and for that you just use the WHERE argument of the DoCmd.OpenReport command, using the PK value as your criterion.
So, yes, you should use the same recordsource. Why would anyone consider that a problem?