I have an odd problem with MS Access 2013 at the moment. It keeps returning "Property Not Found" when I query it with a null field.
The query I've created should allow users to enter some, all or none of a postcode and return the matching records. On my laptop (running Access 2016) this query runs fine in all forms, but returns the aforementioned error when the field is left blank.
The query (in SQL mode) is:
WHERE ((Left([Carer Contact Details]![Postcode],Len([Forms]!
[AgeRangeQueryForm]![PostcodeSearch])))=[Forms]![AgeRangeQueryForm]![PostcodeSearch])) OR ((([Forms]![AgeRangeQueryForm]![PostcodeSearch]) Is Null));
There are some extra parts to the query, relating to other parts of the form but they are not relevant here as all other parts of the query are functioning.
I suspect this is an compatibility issue between Access 2016 and 2013. The database was originally made in Access 2016, but I had to port it onto an older system which runs 2013. This is the only difference I can ascertain, and I can't figure out any other reason why it might work on one machine and not the other!
Any help would be appreciated!
Try using Nz:
WHERE
(Left([Carer Contact Details]![Postcode], Len(Nz([Forms]![AgeRangeQueryForm]![PostcodeSearch]))) = Nz([Forms]![AgeRangeQueryForm]![PostcodeSearch]))
OR
([Forms]![AgeRangeQueryForm]![PostcodeSearch] Is Null);
Related
I have code to export MS Access (2016\2013) queries results into Excel spreadsheets that has worked for years.
This is the code (not posting all variables definitions I've on top of it):
strSQL = "select[query].* FROM [query] "
Set qdf = dbs.CreateQueryDef("MKTShare", strSQL)
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel12Xml, "MKTShare", "\\path\file.xlsx", _
True, ""
DoCmd.DeleteObject acQuery, "MKTShare"
The error given is 3251 - Operation Not Supported for This Object Type
I tried two machines, one running WIN10 and one WIN7. Same result. The really strange thing is that this problem arises mainly with crosstab queries. No issue with "standard" select queries. If I transform the xtabquery into table and then export that table, no issue but that this is an extremely inefficient solution as I've lots of query with very big datasets running in loop.
The query shows fine results if I run it from within Access. The problem is when it comes to the transferspreadsheet method.
It happened yesterday after some Windows updates.
I tried to workaround using Output, but it does not work with prefilled Excel templates as it screws up the whole file it is exporting to.
I just ran into this exact issue yesterday. The webpage for a Windows Update that was installed yesterday had a clue in it. It seems a new security related registry key was added to Jet/ACE to prevent connections to remote sources. Not sure why crosstab queries in a TransferSpreadsheet Export are affected (must be behind the scenes in how transfer spreadsheet works), but I can successfully run my command with this update uninstalled.
Here's the link to the update. It was distributed within an office security update (KB4493206).
https://support.microsoft.com/en-us/topic/kb5002984-configuring-jet-red-database-engine-and-access-connectivity-engine-to-block-access-to-remote-databases-56406821-30f3-475c-a492-208b9bd30544
Update: It's a bug introduced in the May 2021 security updates to the MSI versions of Office. Microsoft knows about it and is working on a bugfix. Quoting MVP Tom van Stiphout's answer in the MS Answers thread:
I heard back from MSFT. This is an issue with A2013 and A2016 MSI, and will be likely be fixed in the July update.
We have the same problem. I did some more debugging and managed to create a minimal reproducible example. Apparently, the problem only occurs
in Access 2013 with KB4493206 installed (probably in Access 2016 MSI with the corresponding KB installed as well, but I can't verify that, since I only have the C2R version of Access 2016),
when a crosstab query is exported with DoCmd.TransferSpreadsheet and
the query references an Access user interface control.
Here are the full repro instructions:
Create a new Access database.
Create a new table Table1 with fields ID (Long Integer) and MyText (Text) and the following records:
ID: 1, MyText: A
ID: 2, MyText: B
Create a new empty form Form1 with a text box Text0 and save it.
Open the form and enter 1 in the text box. Press "Tab" to "save" the value and leave the form open.
Create a new crosstab query CrosstabQuery1 with the following SQL:
PARAMETERS [Forms]![Form1]![Text0] Long;
TRANSFORM First(Table1.MyText) AS FirstValueOfMyText
SELECT Table1.ID
FROM Table1
WHERE ((([Forms]![Form1]![Text0])=1))
GROUP BY Table1.ID
PIVOT Table1.ID;
(Yes, that transformation is pointless and referencing form controls in queries is bad practice, but this is just a minimal repro example.)
Execute the crosstab query to confirm that it works. Save and close it. (Don't open it in design view, or you'll have to fix a few design-time-only things that don't affect the SQL before being able to save it.)
In the immediate window of the VBA code editor execute:
DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel12Xml, "CrosstabQuery1", "C:\temp\repro.xlsx"
Expected result: The result of the crosstab query is exported to Excel.
Actual result (on Access 2013 with KB4493206 installed): Error "3251 - Operation Not Supported for This Object Type"
I have also reported this bug on the Microsoft forums.
I solved this issue by disabling caching for the database.
I am very new to access and Microsoft technologies. So this might be a very silly question but I have already spent a couple of days on this issue.
I have linked a share point list with an access database and try to run an update query like below to update two date fields.
UPDATE [Table_Name]
SET [Table_Name].Start = [Table_Name].[Start]+168,
[Table_Name].[End] = [END]+168;
Every time this is giving below error,
The Microsoft Access database engine could not find the object ''. Make sure the object exists and that you spell its name and the path name correctly. If '' is not a local object, check your network connection or contact the server administrator.
I have full access on this list and able to run select queries but update queries are giving this error, I have tried to run a basic update query and that also gives the same error.
I have also tried to delete the link and create again but no luck.
Please help me to resolve this issue...any pointer is highly appreciated.
regards,
Vaibhav
I am try to migrate from access 2003 to 2016 When I am importing my objects everything is fine. Only,on the process of importing 3 tables, I am getting this error.
System resource exceeded
They are big tables too.
There is no hotfix for access 2016, Total table quantity around 100 tables
If you help me I really appreciate
Found solution here:
https://answers.microsoft.com/en-us/msoffice/forum/all/ms-access-2016-system-resource-exceeded/df80f64a-f233-467e-89df-f05a8d58bc77
In short:
task manager/processes tab, find msaccess, right click and select set affinity.... option. I had 6 CPUs ticked (0 to 5). I un-ticked them all and just ticked the 0 CPU.
Since currently there is no hot fix for 2016 version you have to merge either to 2010 or 2013. Then you can try merging to 2016.
Please check this link:
https://social.technet.microsoft.com/Forums/en-US/aedecca8-aa7d-417f-9f03-6e63e36f0c5d/access-2016-system-resources-exceeded?forum=Office2016setupdeploy&prof=required
Not sure if this will help you, but I've managed to resolve this error by wrapping fields referenced in the WHERE clause with Nz e.g.
instead of
WHERE ReportDate = Date
use
WHERE Nz(ReportDate,ReportDate) = Date
It's strange but it seems to work for me, I've found the issue is often related to indexed fields, so I always add it to those fields first
I am trying following query in MS Access 2010 database:
Query:
SELECT ID, Title, Priority, Workflow_Instance_Step_ID:ID
FROM Task
Error:
Error Source: Microsoft Office Access Database Engine
Error Message: Syntax error (missing operator) in query expression 'Workflow_Instance_Step_ID:ID'
I know that field "Workflow_Instance_Step_ID:ID" is giving error as it has ':' operator, but I cant change it as it it coming from share point list.
I have tried '[Workflow_Instance_Step_ID:ID]' but still its giving an error.
Please give me your suggestion on the same.
I am unable to recreate your issue, at least with a native Access table in Access 2010. I created a table named [baz] with a single text field named [foo:bar]
foo:bar
-------
this
is
a
test
and the query
SELECT [foo:bar] FROM baz;
works fine, so a field name containing a colon character does not seem to cause problems for Access SQL as such.
An ODBC linked table to a SQL Server table with the same structure does not cause problems either.
In both cases the queries were run from within Access 2010 itself.
So we might be in diagnosis mode, so lets try
SELECT * FROM Task
and then look at the FieldNames that come back.
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