ADO Updateable Queries - error when a one of the joined tables has no record - sql

I use the 'updateable query' feature of ADO, being able to select a dataset from several tables and criteria and display it in a grid or some other UI for the user to browse and edit.
However, and I'm surprised I've not hit this problem before now, when one of the joined tables doesn't have a record for the (master) key, and the user tries to edit a field in that table, ADO gives the famous "Row cannot be located.." error on post.
As far as I understand this error, the ADO driver is trying to locate the record in order to update its fields - and, of course, in this instance, there is no record to find. What I was expecting in these circumstances would be that the ADO driver would issue the equivalent of an UPDATE query for the main table, but an INSERT query for the subsidiary table.
Has anyone else come across this problem and found a workround?
The ADO driver used is the Jet 4.0 OLE DB Provider connecting to an Access (mdb) database.
I have ensured that the primary keys fields for both tables are available in the query dataset for the driver to utilise.
Here is a basic version of the SQL I have using:
SELECT
Table1.CustomerNo, Table1.Field1, Table1.Fieldn,
Table2.CustomerNo, Table2.Field1, Table2.Fieldn
FROM
Table1
LEFT JOIN Table2
ON Table1.CustomerNo = Table2.CustomerNo
WHERE
Table1.CustomerNo = Newcode;
As an experiment, I tried the same thing in MS Access 2007, and that worked, so there maybe a solution within ADO (but then Access is probably using a different driver).

In the end, I went for the 'hack' solution. The updateable ADO query over 2 tables would only work if
the customer's reocrds existed in both tables. So, I had to check that, and if the relevant record was missing from table2, had to insert it first, before calling the main query. Here is the code:
//Query customer account - open query from Table1 and Table2 tables
TwoTableQuery.Close;
//
//SELECT Table2.CustomerNo
// FROM Table2
//WHERE (Table2.CustomerNo = CustomerCode);
Table2Query.Close;
Table2Query.Parameters[0].Value := CustomerCode;
Table2Query.Open; /
//does the Table2 record exist for this customer?
if Table2Query.RecordCount = 0 then
begin //no, so create a new record
Table2Query.Insert;
Table2Query.FieldByName('CustomerNo').AsString := CustomerCode;
Table2Query.Post;
Table2Query.Close;
end;
//okay, now okay to open main query
TwoTableQuery.Parameters[0].Value := CustomerCode;
TwoTableQuery.Open;
It's not efficient, and also creates records (in Table2) that may not be needed. But it seems the only solution.

First try the locate function to make sure both fields are there. Make a parameter equal to the field if found and boolean true else update or insert new field with the value of the other one. After that you know the entry exists and you can join the fields...or you can use try except finally to first try and execute the statement except if the field is not found then finally create new entry. Put all of that in a repeat until and make sure the until statement uses locate on both tables to see if its found.

Related

ADO SQL query create column if it doesn't exist

I have a query for a report based on an MS Access database (as the program project file). The tables in this database get updated with new fields periodically as new features are added.
We need to be able to support old and new versions of the file for our report, so need to know if there is a way to insert a field into the SQL SELECT query if it does not already exist. (Note: Do not want to create ALTER TABLE type statements, as the field only needs to be added into the result set, not into the table permanently.)
I know you can do something like "" AS [FieldName], but that only applies when you know the field doesn't exist and need to create a blank spot for it (such as when a unioned table does have that field). In this case, the table might have the field so I want to use it if it does, but if it doesn't I want to have it still exist in the query results with a default value.
Any help would be appreciated. (I also know you can force the user to update the file, but that option was stated as "only last resort".)
Thanks,
Chris

UPDATE query is not "an updateable query" [duplicate]

On some Microsoft Access queries, I get the following message: Operation must use an updatable query. (Error 3073). I work around it by using temporary tables, but I'm wondering if there's a better way. All the tables involved have a primary key. Here's the code:
UPDATE CLOG SET CLOG.NEXTDUE = (
SELECT H1.paidthru
FROM CTRHIST as H1
WHERE H1.ACCT = clog.ACCT AND
H1.SEQNO = (
SELECT MAX(SEQNO)
FROM CTRHIST
WHERE CTRHIST.ACCT = Clog.ACCT AND
CTRHIST.AMTPAID > 0 AND
CTRHIST.DATEPAID < CLOG.UPDATED_ON
)
)
WHERE CLOG.NEXTDUE IS NULL;
Since Jet 4, all queries that have a join to a SQL statement that summarizes data will be non-updatable. You aren't using a JOIN, but the WHERE clause is exactly equivalent to a join, and thus, the Jet query optimizer treats it the same way it treats a join.
I'm afraid you're out of luck without a temp table, though maybe somebody with greater Jet SQL knowledge than I can come up with a workaround.
BTW, it might have been updatable in Jet 3.5 (Access 97), as a whole lot of queries were updatable then that became non-updatable when upgraded to Jet 4.
--
I had a similar problem where the following queries wouldn't work;
update tbl_Lot_Valuation_Details as LVD
set LVD.LGAName = (select LGA.LGA_NAME from tbl_Prop_LGA as LGA where LGA.LGA_CODE = LVD.LGCode)
where LVD.LGAName is null;
update tbl_LOT_VALUATION_DETAILS inner join tbl_prop_LGA on tbl_LOT_VALUATION_DETAILS.LGCode = tbl_prop_LGA.LGA_CODE
set tbl_LOT_VALUATION_DETAILS.LGAName = [tbl_Prop_LGA].[LGA_NAME]
where tbl_LOT_VALUATION_DETAILS.LGAName is null;
However using DLookup resolved the problem;
update tbl_Lot_Valuation_Details as LVD
set LVD.LGAName = dlookup("LGA_NAME", "tbl_Prop_LGA", "LGA_CODE="+LVD.LGCode)
where LVD.LGAName is null;
This solution was originally proposed at https://stackoverflow.com/questions/537161/sql-update-woes-in-ms-access-operation-must-use-an-updateable-query
The problem defintely relates to the use of (in this case) the max() function. Any aggregation function used during a join (e.g. to retrieve the max or min or avg value from a joined table) will cause the error. And the same applies to using subqueries instead of joins (as in the original code).
This is incredibly annoying (and unjustified!) as it is a reasonably common thing to want to do. I've also had to use temp tables to get around it (pull the aggregated value into a temp table with an insert statement, then join to this table with your update, then drop the temp table).
Glenn
There is no error in the code. But the error is Thrown because of the following reason.
- Please check weather you have given Read-write permission to MS-Access database file.
- The Database file where it is stored (say in Folder1) is read-only..?
suppose you are stored the database (MS-Access file) in read only folder, while running your application the connection is not force-fully opened. Hence change the file permission / its containing folder permission like in C:\Program files all most all c drive files been set read-only so changing this permission solves this Problem.
I know my answer is 7 years late, but here's my suggestion anyway:
When Access complains about an UPDATE query that includes a JOIN, just save the query, with RecordsetType property set to Dynaset (Inconsistent Updates).
This will sometimes allow the UPDATE to work.
Thirteen years later I face the same issue. DISTINCTROW did not solve my problem, but dlookup did.
I need to update a table from an aggregate query. As far as I understand, MS Access always assumes that de junction between the to-update table and the aggregate query is one-to-many., even though unique records are assured in the query.
The use of dlookup is:
DLOOKUP(Field, SetOfRecords, Criteria)
Field: a string that identifies the field from which the data is retrieved.
SetOfRecords: a string that identifies the set o record from which the field is retrieved, being a table name or a (saved) query name (that doesn’t require parameters).
Criteria: A string used to restrict the range of data on which the DLookup function is performed, equivalent to the WHERE clause in an SQL expression, without the word WHERE.
Remark
If more than one field meets criteria, the DLookup function returns the first occurrence. You should specify criteria that will ensure that the field value returned by the DLookup function is unique.
The query that worked for me is:
UPDATE tblTarifaDeCorretagem
SET tblTarifaDeCorretagem.ValorCorretagem =
[tblTarifaDeCorretagem].[TarifaParteFixa]+
DLookUp(
"[ParteVariável]",
"cstParteVariavelPorOrdem",
"[IdTarifaDeCorretagem] = " & [tblTarifaDeCorretagem].[IdTarifaDeCorretagem]
);
I would try building the UPDATE query in Access. I had an UPDATE query I wrote myself like
UPDATE TABLE1
SET Field1 =
(SELECT Table2.Field2
FROM Table2
WHERE Table2.UniqueIDColumn = Table1.UniqueIDColumn)
The query gave me that error you're seeing. This worked on my SQL Server though, but just like earlier answers noted, Access UPDATE syntax isn't standard syntax. However, when I rebuilt it using Access's query wizard (it used the JOIN syntax) it worked fine. Normally I'd just make the UPDATE query a passthrough to use the non-JET syntax, but one of the tables I was joining with was a local Access table.
This occurs when there is not a UNIQUE MS-ACCESS key for the table(s) being updated. (Regardless of the SQL schema).
When creating MS-Access Links to SQL tables, you are asked to specify the index (key) at link time. If this is done incorrectly, or not at all, the query against the linked table is not updatable
When linking SQL tables into Access MAKE SURE that when Access prompts you for the index (key) you use exactly what SQL uses to avoid problem(s), although specifying any unique key is all Access needs to update the table.
If you were not the person who originally linked the table, delete the linked table from MS-ACCESS (the link only gets deleted) and re-link it specifying the key properly and all will work correctly.
(A little late to the party...)
The three ways I've gotten around this problem in the past are:
Reference a text box on an open form
DSum
DLookup
I had the same issue.
My solution is to first create a table from the non updatable query and then do the update from table to table and it works.
Mine failed with a simple INSERT statement. Fixed by starting the application with 'Run as Administrator' access.
MS Access - joining tables in an update query... how to make it updatable
Open the query in design view
Click once on the link b/w tables/view
In the “properties” window, change the value for “unique records” to “yes”
Save the query as an update query and run it.
You can always write the code in VBA that updates similarly. I had this problem too, and my workaround was making a select query, with all the joins, that had all the data I was looking for to be able to update, making that a recordset and running the update query repeatedly as an update query of only the updating table, only searching the criteria you're looking for
Dim updatingItems As Recordset
Dim clientName As String
Dim tableID As String
Set updatingItems = CurrentDb.OpenRecordset("*insert SELECT SQL here*");", dbOpenDynaset)
Do Until updatingItems .EOF
clientName = updatingItems .Fields("strName")
tableID = updatingItems .Fields("ID")
DoCmd.RunSQL "UPDATE *ONLY TABLE TO UPDATE* SET *TABLE*.strClientName= '" & clientName & "' WHERE (((*TABLE*.ID)=" & tableID & "))"
updatingItems.MoveNext
Loop
I'm only doing this to about 60 records a day, doing it to a few thousand could take much longer, as the query is running from start to finish multiple times, instead of just selecting an overall group and making changes. You might need ' ' around the quotes for tableID, as it's a string, but I'm pretty sure this is what worked for me.
I kept getting the same error until I made the connecting field a unique index in both connecting tables. Only then did the query become updatable.
Philip Stilianos
In essence, while your SQL looks perfectly reasonable, Jet has never supported the SQL standard syntax for UPDATE. Instead, it uses its own proprietary syntax (different again from SQL Server's proprietary UPDATE syntax) which is very limited. Often, the only workarounds "Operation must use an updatable query" are very painful. Seriously consider switching to a more capable SQL product.
For some more details about your specific problems and some possible workarounds, see Update Query Based on Totals Query Fails.
I kept getting the same error, but all SQLs execute in Access very well.
and when I amended the permission of AccessFile.
the problem fixed!!
I give 'Network Service' account full control permission, this account if for IIS
When I got this error, it may have been because of my UPDATE syntax being wrong, but after I fixed the update query I got the same error again...so I went to the ODBC Data Source Administrator and found that my connection was read-only. After I made the connection read-write and re-connected it worked just fine.
Today in my MS-Access 2003 with an ODBC tabla pointing to a SQL Server 2000 with sa password gave me the same error.
I defined a Primary Key on the table in the SQL Server database, and the issue was gone.
There is another scenario here that would apply. A file that was checked out of Visual Source Safe, for anyone still using it, that was not given "Writeablity", either in the View option or Check Out, will also recieve this error message.
Solution is to re-acquire the file from Source Safe and apply the Writeability setting.
To further answer what DRUA referred to in his/her answer...
I develop my databases in Access 2007. My users are using access 2007 runtime. They have read permissions to a database_Front (front end) folder, and read/write permissions to the database_Back folder.
In rolling out a new database, the user did not follow the full instructions of copying the front end to their computer, and instead created a shortcut. Running the Front-end through the shortcut will create a condition where the query is not updateable because of the file write restrictions.
Copying the front end to their documents folder solves the problem.
Yes, it complicates things when the users have to get an updated version of the front-end, but at least the query works without having to resort to temp tables and such.
check your DB (Database permission) and give full permission
Go to DB folder-> right click properties->security->edit-> give full control
& Start menu ->run->type "uac" make it down (if it high)
The answer given above by iDevlop worked for me. Note that I wasn't able to find the RecordsetType property in my update query. However, I was able to find that property by changing my query to a select query, setting that property as iDevlop noted and then changing my query to an update query. This worked, no need for a temp table.
I'd have liked for this to just be a comment to what iDevlop posted so that it flowed from his solution, but I don't have a high enough score.
I solved this by adding "DISTINCTROW"
so here this would be
UPDATE DISTINCTROW CLOG SET CLOG.NEXTDUE

SQL Server Query in Access

I currently have a bunch of queries that have been input into macros, which are called by one parent macro in Access 2007.
At the end of the process I have to switch to the central DB from which we have several ODBC connections and run this query:
update A
set A.PCP_End_Date = B.PCP_End_Date
from dbo.PCP_History A
outer apply (SELECT (min(PCP_Start_Date) -1) PCP_End_Date from dbo.PCP_History x
WHERE x.PCP_Start_Date > A.PCP_Start_Date AND x.PartD_Rx_ID=A.PartD_Rx_ID)B
Is there any way to do this in Access?
What I'm trying to do is say I have two records:
First record is original PCP, PCP_Start_Date, PCP_End_Date (null), and PCP_Update_Date
Then I have a new record:
new PCP, PCP_Start_Date (04-01-2014), PCP_End_Date(Null),PCP_Update_Date(DATE())
I want to set the first records PCP_End_Date to the day before the new records PCP_Start_Date - so in this scenario it would be 03-31-2014 to the end date of the first record.
Hope this makes sense. Let me know. Thanks!
So I solved this myself.
It's called a Pass-through query.
Because I identify the ODBC connection, I put this same syntax into a query, but select Pass-through. A properties window comes up and asks you to select your ODBC connection str.
This worked very well. Awesome.

ClientDataset.RefreshRecord no longer works in Delphi XE for joined tables - any workarounds?

TClientDataset.RefreshRecord no longer generates the table join part of SQL when trying to refresh a record on a ClientDataset connected to a dataset with a joined table in the SQL statement.
As a result, calling this method results in SQL error "invalid column names" for each field not in the main table.
This was not a problem in Delphi 2010 and earlier.
The error occurs with both DBX4 or BDE components connected to the TClientDataset and thus it is highly likely the issue is a problem with changes to TClientDataset code.
To replicate this problem:
Create a new app in Delphi XE with only a single form and drop the required database components on it (TSQLMonitor, TSQLConnection, TSQLQuery, TDatasetProvider, TClientDataset, TDatasource, and TDBGrid) and bind them to each other.
Created a simple SQL statement with a table join and placed this in the TSQLDataset.SQL property.
The SQL statement included just two fields - the key field of the main table, and a field from a joined table - for example in pseudocode:
Select
MainTable.IntegerKeyField
, JoinedTable.JoinField
FROM MainTable
LEFT OUTER JOIN JoinedTable ON MainTable.LookupFieldID = JoinedTable.JoinKeyField
Add both of these fields as persistent fields in both TSQLQuery and TClientDataset with Provider Flag for the key field including pfInKey (RefreshRecord will not work if it does not know which field is the key hence persistent fields is a must).
Add two buttons on the form - one just opens the Clientdataset and the 2nd button calls clientdataset.refreshrecord;
Run the app, press button to open dataset and data displays in the grid.
Press the Refresh Record button, and you will get SQL error "invalid column name" for the joined field.
Close the app, open the SQLMonitor log and in the refresh record SQL statement that Delphi generated, you will see it has not included the table join statement.
====
I would really appreciate any ideas on how to fix this.
Try using a view on the database to implement the required join. Then the delphi component can just select from view_name rather than have to handle the join itself.

Access 2007 to Oracle 10g linked table -- query with flawed results, but no errors thrown

Access 2007 databases querying linked oracle 10g tables are returning flawed result sets when using the WHERE clause to filter-out unwanted records. Oddly, some filtering is happening, but not reliably.
I can reliably demonstrate/produce the problem like this:
Create a *new* database with Access 2007.
Create a second *new* database with Access 2007, and then "save-as" 2000.
Create a third *new* database with an older version of Access.
Run the following query in each database:
SELECT
STATUS,
ID,
LAST_NAME,
FIRST_NAME
FROM
Oracle10g_table
WHERE
STATUS="A"
In both databases created with Access 2007, running this query will give you a result set in which some of the records where (STATUS="A") = false have been filtered out, but not all of them.
In databases created with older versions of access, the where clause filters properly, and the result set is correct.
STATUS is a text field
The table is a "linked" table to an Oracle10g Database
The table has 68k rows
I've tested my timeout at 60, 1000 and 0
Has anyone run into this problem?
I wonder if this is a new "feature" of access that will also affect 2010. Could this have anything to do with ODBC?
Thanks for any help,
- dave
MORE...
I just tried an alternate form of the query, using HAVING instead of WHERE, and it worked! Problem is, besides that this shouldn't change anything (yes -- more virtual tables, but shouldn't change the end result) my end-users will be using the Access 2007 visual query designer, not typing SQL directly, which is going to default any criteria they enter into a WHERE.
My hunch is that one of your ODBC drivers used by Access to connect to Oracle is treating "A" as a column name not the literal 'A'. Have you tried single quotes on the 'A'? In Oracle double quotes are used to reference column names, is there a column named "A" by any chance?
Oracle Query Example #1
Select object_name from all_objects
where "OBJECT_NAME" = 'DUAL'
Oracle Query Example #2
with example as (
Select object_name as "Fancy Column Name" from all_objects
)
select * from example
where "Fancy Column Name" = 'DUAL'
I've had a similar problem. In my case, changing the ODBC driver worked, but I could also just change the 'unique record identifier' to a column with no nulls in it. It still doesn't have to be the "right" unique record identifier.
This turned-out to be an ODBC-related issue. Our tech support service unit installs connectivity on each of our workstations -- they program it themselves, and who knows what they actually put into it -- but the net result is that when you link to an ODBC datasource with Access (of any version), our network servers show-up in the 'machine data source' tab, so we just click on the one we want and away we go. This has worked well until Access 2007.
What I did was create a "new" machine data source, which let me choose the ODBC driver myself (instead of making me use the one our tech support folks created). I picked "Microsoft ODBC for Oracle", entered the name of the server I wanted, and that all it took. Now the WHERE-clause inconsistent filtering problem is solved (I hope).
The only thing remaining is to send this back to our tech support folks, so they can clean-up their installation. Should I ask for hazard pay? :-) hehe