MS Access 2010 brings an error (Enter Parameter value) when I try to perform the following very simple Union query:
SELECT
[1_Toyota_2013_mit_PFC_2].[FC-Teile-Nr]
FROM 1_Toyota_2013_mit_PFC_2
UNION
SELECT
[1_Toyota_2013_ohne_PFC_2].[FC-Teile-Nr]
FROM 1_Toyota_2013_ohne_PFC_2;
Everything is specified... I understand that having "-" in the names forces me to use brackets. I am doing that, but it still causes an error. If I simply press OK, then I do get the correct result. But I'd like to have the error not pop up.
Any idea why this happens?
Thanks!
My query was based on two sub queries. The unspecified parameter was a calculated field in one of the sub queries that I had created. After creating the field, I subsequently changed the name of one of the tables, and while Access updated all the other query fields, it did not ofcourse update my manually created calculation.
Thanks for the probing questions that led me to the answer 4dmonster!
Related
I have a really old database (created in 2002) where I need to select the unique values and copy them to another table.. unfortunately the select distinct is not working on the field.
There comes always the error that the field is too small to add the data.
As I have seen is there a restriction to the length of the fields. The column is set to long text. Do you have something like a workaround / solution how to solve it fast?
I have also tried to change the database to accdb from mdb without success.. still the same error.
Each field has 318 characters. I have like 5000 rows.
Thanks in advance!
The column is set to long text.
This is well known issue...
This should help: MS Access: "The field is too small to accept the amount of data you attempted to add" error when running a query
For further details, please see: The Memo data type is now called “Long Text”
Searching this problem returns quite a few search hits, but many off-track answers, so I'm posting a concise description here, and answer below.
The problem afflicts Microsoft Access 2010, and some versions before. Access 2013 renames Memo type to Long Text. I don't know if it has the same problem.
The root problem is associated with running an UPDATE query on a table with a memo field, in certain particular circumstances. This might be an UPDATE query composed in the visual query window, or some VBA running SQL via DAO or ADO or similar. Or it could arise while updating via a form.
(The current post is concerned with this occurrence just within an Access database, though elsewhere you will find discussion of similar-sounding issues when Access is connected to an external database server.)
Instead of generating an immediate and obvious error alert, Access (or perhaps Jet) places the value #Error (which is not just the string "#Error"!) into the Memo field. This might easily go unnoticed until some later time, resulting in visible errors such as:
-- You use Compact and Repair. That seems to complete, but Access quietly adds a MSysCompactError table with a couple of rows. One error -1611 complains that Access was stopped and couldn't complete the operation. A second, more-specific-seeming error complains that it can't find field "Description". That appears to be an internal error that has no relevance.
-- You try to copy the table to another database. Access gives an error complaining that another user is using the table or has updated the table, and won't complete the operation.
-- Other operations on the rows that, unnoticed by you, happen to contain the #Error values fail.
Regardless, the root problem is whatever causes the #Error values to get placed into the Memo fields in the first place.
Many posters have noted that it occurs if the UPDATE attempts to put strings longer than about 2000 characters into the Memo field. That's a surprise, as Memo fields should be able to hold 1 gig characters or more depending on version, even if it only allows 65k through the UI.
So why does the error occur when Updating using >2000 characters?
The key factor that provokes this error is the Memo field having an index. Apparently, although the Memo type field can hold a bazillion characters, the index can't deal with more than about 2000.
Knowing that this is the precipitating factor, probably a number of workarounds come to mind. First, you can obviously just disable the index. This solution is easy to verify in a dummy database: Create two tables containing Memo fields, one with an index and the other without. Run update queries that put >2000 characters into each Memo and note the results.
But perhaps you think you need the index? Your use case might be satisfied if you create a second field that will contain an initial substring of the main Memo (shorter than 2000 characters), and index that instead. This could be used for sorting purposes for example. In most cases, where a memo contains narrative information, it's unlikely that the memo data values differ only after 2000 characters. Or perhaps you can devise a hash function and make a separate column of that.
What if you have a database that already contains these #Error values? Some advice floating around on the web, especially in relation to downstream problems like failure of Compact and Repair, suggests that your database is corrupt and should be abandoned. I'm not so sure. If you can delete the #Error-afflicted rows, then delete the index, and then recreate the deleted rows, you may be back in business. Compact and Repair should run properly at that point, giving some confidence that you fixed the offending part. (Make backups along the way, obviously.)
Workaround solution
Create two macros (Macro1 Macro2)
Macro 1
Get all the necessary information from the open form which includ this long text and close it.
Macro 2
Insert all needed actions (starting with the update query that you get error)
Create a form (Form_on_error) with only a button that run Macro2
Finally add at the end of macro 1
On Error
Go to :Macro Name
Macro Name: On_Error_2590
RunMacro Macro2
Submacro On_error_2590
OpenForm (Form_on_error)
End Submacro
.......and it works !!!
So, only when the update query get error, the user must click the button on the form : Form_on_error
I am attempting to create a sql statement in XE8 at runtime to search an oracle database based on the value in a textbox. I find multiple different ways that attempt to explain this online, but I am not understanding what it is asking.
I want to search a server based on a select statement and populate TDB components (labels only) based on the data. The furthest I have gotten is to get data populated, but the where
' ... somevalue = ' + textbox.text;
seems to have no effect.
What components do I need to make this happen? I am connected to the database, and it appears that I can get some kinda data out of it, but I can't seem to figure out how to filter the results. Obviously, I cannot create this sql statement at design time as the value of textbox.text will change depending on the user's input.
My error was in how to dynamically change what the data aware components got data as it would not always be the same. I had to manually go in and modify their datafield properties. Once I did this, my query functioned correctly.
I'm troubleshooting a database developed by someone else in my organization.
I have an SQL Statement with a legitimate
SELECT Statement...FROM My_Download WHERE Age>=75;
Why would this prompt me for input when I run this SELECT Statement rather than displaying the results?
It means the query can't find all the requested fields in the source My_Download. Try rebuilding the query and you should spot the problem. Also, check the properties (a panel visible when in Design or SQL view). If you find an extraneous Filter or Order string, remove it.
I have a query that accepts input from a form. The query works as expected when I run it, manually typing in the form input values. However, when I run the query from the form, the query returns blank - no error, just blank.
I don't understand what's causing it - at it's most basic, the user is simply entering a Start and Stop date. I'm entering the data exactly the same, and made sure my form text box is formatted as a date.
Furthermore, when I run the form, I am not prompted for any values, so I know it's reading them accurately. This system works for several similar queries, but not this one.
What I've tried
Changing the format of the text box to specify Short Date (which is how I type it)
Visually confirming the values are making it from the form to the hidden staging area the query references - these values match what I manually enter into the prompts
The query I'm runnning references another query; running the other one by itself only yields one set of "date" prompts, not two. So I created a seperate date input box for each to read off of, but to no avail
Question: Does Access try and format (or not format) parameter input boxes differently than it would handle form references?
Additional detail - when I run the query manually, it prompts me for the dates twice - I don't know why or it's pertinent, but I thought I'd mention it.
use instead Temporary variable in your Query for the specified dates. After you select the dates from the Form, make sure that the values are assigned to the temporary variables and that you requery the record source of the form
I was able to get this working by tweaking my query in the designer - specifically by splitting up my expression into multiple pieces and writing the criteria in segments.
I'm not sure why this did the trick, but it at least got me where I needed to go.
Good luck to anyone else experiencing this!