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.
Related
I'm new to CDS/Dataverse, coming from the SQL Server world. I created a new Dataverse table and there are over a dozen columns in my "new" table (e.g. "status", "version number"). Apparently these are added automatically. Why is this?
Also, there doesn't seem to be a way to view a grid of data (like I can with SQL Server) for quick review/modification of the data. Is there a way to view data visually like this?
Any tips for a new user, coming from SQL Server, would be appreciated. Thanks.
Edit: clarified the main question with examples (column names). (thanks David)
I am also new to CDS/Dataverse, so the following is a limited understanding from what I have explored so far.
The idea behind Dataverse is that it gives you a pre-built schema that follows best-practice for you build off of, so that you spend less time worrying about building a comprehensive data schema, creating tables, and how to relate them all together, and more time building applications in Power Apps.
For example, amongst the several dozen tables it generates from the get-go is Account and Contact. The former is for organisational entities and the latter is for single-person entities. You can go straight into adding your user records in one of these tables and take advantage of bits of Power Apps functionality already hooked up to these tables. You do not have to spend time thinking up column names, creating the table, making sure it hooks up to all the other Dataverse tables, testing whether the Power Apps functionality works with it correctly etc.
It is much the same story with the automatically generated columns for new tables: they are all there to maintain a best-practice schema and functionality for Power Apps. For example, the extra columns give you good auditing with the data you add, including when a row was created, modified, who created the row etc. The important thing is to start from what you want to build, and not get too caught up in the extra tables/columns. After a bit of research, you'll probably find you can utilise some more tables/columns in your design.
Viewing and adding data is very tedious -- it seems to take 5 clicks and several seconds to load the bit of data you want, which is eons in comparison to doing it in SQL Server. I believe it is how it is due to Microsoft's attempt to make it "user friendly".
Anyhow, the standard way to view data, starting from the main Power Apps view is:
From the right-hand side pane, click Data
Click Tables
From the list of tables, click your table
Along the top row, click Data
There is an alternative method that allows you to view the Dataverse tables in SSMS – see link below:
https://www.strategy365.co.uk/using-sql-to-query-the-common-data-service/
To import data in bulk:
Click on Data from the top drop-down menu > Get data.
Importing data from Excel is free. To import from other sources, including SQL Server, I believe is a paid service (although I think you may be able to do this on the free Community Plan).
I am trying to do an audit trail in Microsoft Access and I need a way to track when users open a table, not a form. Is there a way to run a function every time a table is opened?
Unfortunately, no events are fired when opening tables or queries in a MS Access database. If you do need to have this functionality, there are two options that I can think of, both involve hiding or restricting direct access to the tables:
Build a dashboard form, with a command button to open each table and use the Click event of the button to perform your auditing procedure. you'll be able to audit the opening of each table, but not closing. Use database table triggers to do the audit of data updates.
Create datasheet view forms of all your tables, and give access to these forms to the user instead of the tables. You'll be able to use all the supported form events to perform your audit, such as opening, closing, data updates.
You can build a combination of both to achieve your goal.
Unfortantly this would have to be done at the UI or application level, not the data engine level.
Access since 2010 does have table events and procedural code that can run at the engine level (store procedures). These table triggers and procedural code run independent of Access, and VBA code. In fact if .net or outside applications (non access) even update Access tables with ODBC, then these table triggers and store procedure code will run.
So, these features in the Access data engine (ACE) would allow some kind of audit trail and logging system to be created.
However, JUST WHO opens a table? No, that feature is not available in even SQL server, and most data engines don't have this ability (with the exception of trace features, but these are for testing, and debugging, and cause significant slow downs if such kinds of "logging" is turned on. In fact, ACE also has what is called show-plan. This will show the query plan used by ACE data engine for each and every query. But again, as noted, this kind of logging is for debugging and not suitable for tracking the "act" of a table open.
However, like SQL server, the Access data engine does have table event triggers, but they only run for updates, inserts, deletes.
Even with SQL server, you are limited to such table events. To be fair, SQL server does also have events for "DML" operations (ACE does not). So, drop of tables, or even schema modifications can fire events, the Access ACE engine cannot.
All in all?
Even with SQL server, to track/log who opend what table? You quite much need to do this at the UI/applicaiton level and not the data engine level.
If the Access application is built well, then users will never open a table directly anyway - and this holds true for any well written program - you never open/use tables directly anyway the instant you build a application in Access as opposed to just editing and view some tables like how one would in say Excel.
So, you would have to attach some code in the forms on-load. It is quite common to do this, and in several applications, we for example have a "edit" button on a form. The form can be viewed, but to edit, you have to first un-lock. When you click on un-lock, then that event is logged. As a result, we can see a nice list of all users (people) who editing that record. But, we don't log "just" the act of having opened and view the form that displays data from the table.
However, it certainly would be possible to log, and track such actions, but as noted, this would occur at the application level - not data engine level.
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?
Good Afternoon,
A customer has provided me with a spreadsheet file his team uses to provide quotes for a product. The spreadsheet has extensive data in underlying sheets and calls those sheets as part of the numerous formulas on the quote sheet.
I've been tasked with web-enabling this tool such that the quotes can be generated on the client's website, hosted in a shared environment, running ASP.net 3.5 webforms. The quote web form will be in a Restricted portion of the website controlled by ASP.net membership API.
Are there 3rd party tools that do well with this sort of thing?
Thanks,
Sid
I've once been asked to do something similar. I refused. Someone else tried this and it became a complete failure. That's because your design is based upon the structure of a spreadsheet.
When I was called back to help on this project, I kicked the previous code into a large bin, which will stay closed until Hell freezes over! I then started analysing the Excel sheets, extracting the business logic and writing them down as documentation. This allowed me to create a good design to set up the first version of a new project, which wasn't based upon the Excel sheet, just on the business logic in the sheet.
Don't be tempted to fall into this trap! It sounds too easy but in reality, it's way too expensive as a solution because of all the problems that you will encounter!If your customer really needs to have something to use real fast, start with .NET (VS2008 with latest service packs or better) and SQL Server. First create a simple database structure to contain the quotes. Add as many relations as needed. Then, using VS2008, create a new project based on the "Dynamic Data Entities Web Application" which will use the Entity Framework to connect to the database. Make sure the entity framework is connected to your database and all data is provided to it. (By adding an "ADO.NET Entity Data Model" to it.) Compile it, put it on the web server and version 0.1 should be ready. It will allow your customer to continue data entry, although in a bit primitive way, while maintaining the data integrity of it all. It still isn't good enough to expose to the outside World but it makes it easier to get rid of the data part of the Excel spreadsheet. (And technically, it should be possible to also add a RESTful service around the entity model within an hour to allow Excel to read data from a web service instead.)
When this start page has been created, your customer can get used to data entry through web pages while you have some time to analyse their spreadsheet a bit more to optimize the data model and to create custom logic and better pages for data entry.
Basically, this is the approach that I used. My customer had data in Excel sheets which was exported to an Access database which was used as read-only data for users of his application. He used Excel to keep the data up-to-date. But when multiple users started to maintain the data in the same Excel sheet, he got in big trouble, losing the integrity and data of the Excel sheets multiple times.
I first created a simple data model around the Excel data with the Entity framework/DDS for easier data entry and then I could optimize the database structure while the customer just continued to modify the data. Occasionally, I'd update the database structure, adding more relations and restructuring the data to be more optimized and at one point I added the RESTful service functionality so the customer could get the data as XML through a simple web request. Now the customer has completely forgotten about the Excel sheet and is using the website full-time. He has accepted the fact that turning it into some fancy website will cost a lot of time but the current situation is quite acceptable.
This approach succeeded where previous attempts failed simply because I only focused on the data, nothing more. Now I can improve it all using little steps. But step one: analyze the Excel sheet and dump the data in a database. The Entity framework will allow you to quickly build simple sites around this without much effort.