I'm trying to build an updatable view in Access for a user. Basically, the underlying tables look like this:
Accounts
--------
accountId
accountName
accountHolder
TransactionStatements
------------
statementId
accountId
received
month
year
The user wants a Query (view) that looks like this:
StatementView
-------------
accountName
accountHolder
year
janReceived
febReceived
marReceived
etc...
The SQL to accomplish this is straightforward using a transpose, but the resulting view is not updatable.
I've also tried doing multiple joins explicitly to accomplish this:
PARAMETERS [Enter Year:] Long;
SELECT accountName, accountHolder, year,
FROM ((Accounts a
INNER JOIN TransactionStatements ts1 ON a.accountID = ts.accountID) 'AND month = 1 (This isn't allowed for some reason?)
INNER JOIN TransactionStatements ts2 ON a.accountID = ts.accountID) 'AND month = 2 (This isn't allowed for some reason?)
WHERE ts1.month = 1 AND ts2.month = 2 AND ts1.year = ([Enter Year:]) AND ts2.year = ([Enter Year:])
But once again the result becomes non-updatable as soon as I add the second INNER JOIN. I've looked at this MS help page, but it hasn't helped me figure out the right way to do this.
It suggests Forms as an alternative, but building a custom form in Access appears to be an even more arcane and convoluted process than writing views.
Any suggestions?
Take a look at this very thorough list of reasons why recordsets are and aren't updateable:
When Recordsets Are Always Updateable
A recordset is always updateable when:
It is based on a single table.
It is based on a query based on a single table.
It is based on a query based on tables with a one-to-one relationship.
When Recordsets Are Never Updateable
A recordset is never updateable when:
It is based on a Crosstab query.
It is based on a Union Query.
It is an Aggregate Query that calculates a sum, average, count or other type of total on the values in a field.
It is an Update Query that references a field in the Update To row from either a crosstab query, select query, or subquery that
contains totals or aggregate functions
Note: By using a domain aggregate function in the Update To row of an update query, you can reference fields from either a crosstab query, select query, or subquery that contains totals or aggregate functions.
It is based on a Query that includes a linked ODBC table with no unique index.
The database was opened as read-only or is located on a read-only drive.
It is a SQL pass-through query.
It is a query whose UniqueValues property is set to Yes. (That is, it is a query with a DISTINCT predicate.)
Cartesian Joins (that is, a query that includes more than one table or query, and the tables or queries aren't joined by a join
line in Design view.)
Query based on three or more tables in which there is a many-to-one-to-many relationship. Note: Though you can't update
the data in the query directly, you can update the data in a form
or data access page based on the query if the form's RecordsetType
property is set to Dynaset (Inconsistent Updates).
Calculated fields. Even if the query itself is updateable, if a column in a query is based on a formula, the field cannot be
updated. However, if the other fields in the formula are updated,
the calculated field will automatically update.
Recordsets Are Updateable Under Certain Conditions
Some queries, especially those involved in a Join, will not be updateable under some conditions, but will be under others. In other queries, even if the query itself is updateable, some of the fields will not be. The following are cases of query problems and their corresponding solutions.
Query based on a Join of tables with no Relationship.
•Problem: If a query is based on two or more tables that DO NOT have a relationship established (with Referential Integrity enabled), the query will be non-updateable.
•Solution: Create a Primary Key or Unique Index on ALL of the fields used in the Join on the "one-side" table. To be clear, this means ONE primary key or unique index based on all of the fields, not separate indexes on each field.
In a query based on a Join of tables with a one-to-many relationship (1:M), you might not be able to edit the data in one or more fields.
Join field from the "one" side
•Problem: If you have a 1:M relationship created between two tables, you cannot change the primary key field (used in the Join) of the table on the "one" side of the relationship.
•Solution: Enable cascading updates between the two tables.
New records, if the "many" side join field doesn't appear in the datasheet
•Problem: In a query based on a 1:M relationship, you can create a new record and fill in the fields that come from the "one" side table, but if the join field from the "many" side table is not visible in the query (that is, the foreign key), you cannot add data to the "many" side fields.
•Solution: Add the join field from the "many" side table (ie, foreign key) to your query to allow adding new records.
New records on the "one" side that are duplicates of other "one" side records.
•Problem: When adding a new record, if you try to type into the "one" side fields, you will be attempting to create a new record. Even if you use the same primary key values, it will give you an error.
•Solution: Add a value to the "many" side join field (foreign key) that matches the "one" side join field (primary key) of an already existing record. The "one" side values will simply appear.
Join field from the "many" side, after you've updated data on the "one" side
•Problem: If you are currently editing fields from the "one" side of the relationship, you cannot change the "many" side join field (foreign key).
•Solution: Save the record; then you'll be able to make changes to the "many" side join field.
New records, if entire unique key of ODBC table isn't output
•Problem: This is different than #5 under Never Updateable. In this case, the primary key of the linked ODBC table exists, but is not added to the query.
•Solution: Select all primary key fields of ODBC tables to allow inserts into them.
Query does not have Update Data permissions
•Problem: Query (or underlying table) for which Update Data permission isn't granted.
•Solution: To modify data, permissions must be assigned.
Query does not have Delete Data Permissions
•Problem: Query (or underlying table) for which Delete Data permission isn't granted
•Solution: To delete data, permissions must be assigned.
Conclusion
The causes of non-updateable recordsets are many and varied. Some have solutions and others don't. Hopefully, this list will help you know the difference.
The above is taken, word for word, from the following blog: This Recordset Is Not Updateable. Why?
I felt it was best to copy and fully attribute rather than try to paraphrase, so that all of the information was given.
The first things I suggest you look at might be that your tables have proper indexing and their relationships are set up properly. Those are usually the two things I gun for first, and they tend to solve most of my own "non-updateable query" issues.
Related
I have a field in a table called "CaseDelay" and a field in a query called "Delay." Both are numbers.
Don't know the best procedure to get the query to run and the field value to update the table field.
Additionally, the field in the query is a calculated field, and I read on Microsoft's website that syntax such as UPDATE won't work with calculated fields.
The expressions that are in the query are difficult nested IIF statements that I couldn't figure out how to write in VBA, but could do it in a query expression.
You'll first need to specify how the records in the query relate to those in the table, such that an update query can unambiguously identify & update the appropriate record in your table for each record in your query.
Typically this would be achieved using unique keys present in both the table & query which may be used to pair up the records in the two datasets.
Once this is ascertained, assuming that the query does not use aggregation, you can use a straightforward update query with a join between your existing query & table, e.g.:
update YourTable inner join YourQuery on YourTable.ID = YourQuery.ID
set YourTable.CaseDelay = YourQuery.Delay
I've a list of records (in excel) which I want to lookup in SQL table to find their entry date in table.
For example I've name of 200 customers in an excel sheet which are also in my SQL table but there are many others as well. I want to compare those users in table and find their date of joining the table i.e the date they were added to the table.
Do you have any column such as "customer_id"? If not, create it in the tables as it will make it easier for you to select and join tables. You can use the alter table statement to add the new column. After adding the columns, join the tables and use the select statement to find the required record.
You must have a key to bind those data. Any other way can be dangerous linking these informations. Maybe, the way is adapt your application or excel to provide this bind between the data.
I'm trying to do a lookup of a field form one table, to update values in another table. I know this can be done easily with a query, but is there a way to do it in a table?
Basically all I'm trying to do is an excel VLOOKUP but in Access. Where if I change the lookup value in my destination table, the value returned will be updated.
You need to join the tables in a query and then set the values of a field in one table to the field in the second table based on the join fields (hope that made sense).
So, for example, if you have:
Table1 with KeyField1 and DescriptionField1
Table2 with KeyField2 and DescriptionField2
If you want to update DescriptionField1 with the values in DescriptionField2 where the KeyField values match you use this SQL:
UPDATE Table1 INNER JOIN Table2 ON Table1.KeyField1 = Table2.KeyField2
SET Table1.DescriptionField1 = Table2.DescriptionField2
The other way is to use a look up field - select Lookup Wizard in the Data Type.
If taking this route I'd advise the ten commandments of Access tables :)
Thou shalt never allow thy users to see or edit tables directly, but
only through forms and thou shalt abhor the use of "Lookup Fields"
which art the creation of the Evil One.
http://access.mvps.org/access/tencommandments.htm
I am working with BDS 2006,MySQL DB (MyDAC components used for connection) and i have a DBGrid component on my form which displays the records from my DB table.
Now i need to JOIN two tables and display the results in my DBGrid
The Resulting view that I should get is the result of the query
SELECT e_salary.e_basic,e_details.e_name
FROM e_details
INNER JOIN e_salary
ON e_details.e_id=e_salary.e_id;
there is one more option to do it as I searched
SELECT
e_salary.e_basic,e_details.e_name
FROM
e_details, e_salary
WHERE
e_details.e_id=e_salary.e_id;
e_details,e_salary are my two tables and e_id is my PRIMARY KEY
Presently I am having 2 DBGrid one is for e_details and other for e_salary
Is it possible to have only 1 DBGrid displaying values from both the Tables? or I have to display 2 separate DBGrid?
If possible then how do I go about it
P.S.- there are more columns to be added in the view and both tables have same no of rows
Thanks in advance
DBGrid displays a dataset data. The data may be result of some SQL query execution. DBGrid, TDataSet and TDataSource do not cary what was the SQL query. Single table SELECT, multi table SELECT with joins, stored procedure call or SHOW command. So, yes - you can use 1 DBGrid to display resultset of your SELECT joining 2 tables.
If both tables have the same number of rows, e_id is primary key for both tables, then why not to have single table, containing columns of both tables ? Also, if you will need to edit your dataset data, then there may be problems to update columns of both tables. And that may be one more argument to have single table.
Although you can use WHERE e_details.e_id=e_salary.e_id instead of JOIN e_salary ON e_details.e_id=e_salary.e_id. The JOIN is preferred, because DBMS gets your intent more explicitly and that is more readable for others.
The DBgrid is probably not the component you need.
Give an eye to the TTreeView
http://delphi.about.com/od/vclusing/l/aa060603a.htm
I have an Access 2003 table with ~4000 records which was made from 17 different tables. Roughly half of these records are duplicates. There is no unique identifying column (id, name etc). There is an id column which was auto filled when the tables were combined meaning that the duplicates aren't completely identical (though this column could be removed if it makes things easier).
I have used the Access Find Duplicates Query Wizard which gives me a list of the duplicated records but won't let me delete them (seriously what use is this query if I can't delete them?). I've tried converting the generated query to a remove query but that changes the number of rows that it finds. I'd alter the sql by hand but it's a bit beyond me and is 7 lines long.
Does anyone know a good way of getting rid of the duplicates?
The reason the find duplicates query won't let you delete the records is because it is basically just an aggregate query, it is counting the number of duplicates it finds and returning the cases where the count is greater than 1.
Consider that if you did make a delete query based on the find duplicates, it would delete all rows that have duplicate values, which is maybe not what you want. You want to delete all but one of the duplicates.
You should try to delete all duplicates of a record apart from one, excluding the ID column in your comparison. I suggest the simplest way to do this is to make a make-table query of all the unique values (Select Distinct Field1, Field2... from MyTable) instead for every field except for the ID field, using the results in a to create a new table of around 2000 records (if half are duplicates).
Then, create an ID column on your new table, use an update query to update this ID to the first matching ID in the original table (you could do this using DLookup, which will return the first EXPRESSION value where CRITERIA is true in DOMAIN).
The DLookup() function returns one
value from a single field even if more
than one record satisfies the
criteria. If no record satisfies the
criteria, or if the domain contains no
records, DLookup() returns a Null.
Since you are identifying the first matching ID based on all the other fields, which are unique values, the unmatched IDs will belong to duplicates. You will be reversing the PK relation, identifying the first matching key given a set of unique fields. After that, you should set the ID to be PK. Of course this assumes the ID has no inherent meaning, and you don't care about keeping one particular ID for a given duplicated row over any of the IDs belonging to the other duplicated rows. This assumes you care about the data in the ID column so you want to preserve it for all remaining rows, otherwise just ignore the DLookup step and do a Select Distinct on all columns apart from the ID.
Use a select with all columns except the ID column:
SELECT DISTINCTROW Column1, Column2, Column3
INTO MYNEWTABLE
FROM TABLE
You can simply swap the names.
This solution will give you a new table with non duplicates.
The following will preserve original IDs and do it in one step:
DELETE FROM table_with_duplicates
WHERE table_with_duplicates.id NOT IN
(SELECT max(id)
FROM table_with_duplicates
GROUP BY duplicated_field_1, duplicated_field_2, ...
)
Now you have the original table with no duplicates and preserved ids.
And always remember to backup you data before trying large DELETEs.
DELETE * FROM table_with_duplicates
WHERE table_with_duplicates.ID In
(SELECT max(ID)
FROM table_with_duplicates
GROUP BY [duplicated_field_1]
HAVING Count(*)>1
)
Actually I Found A very simple solution took a while but it all of your fields across are the same like a complete duplicate record then just make one query with every field and sort by "Group BY". Thus the duplicates will combine and you can just append this information to a new table and rename it the same as the existing table. If you have a primary key field you could just ignore it in the query and then it would still combine the data (assuming that you don't care about the data in the primary field). I don't know why no one has mentioned this solution took me 5 hr. to come up with. :)