Update on a linked table failed

The problem:
"Update or insert of view or function 'function_name' failed because it contains a derived or constant field (#4406)"
in my access database which is linked to SQL server

The reason:
The underlying view is of type "union"

The solution:
change to a single source (not a union select)

Where did all my values go to?

Or: Mess with values that you enter in a datasheet view.
This is the scenario:
There is a form which contains a sub form which is linked to values in a text box on the form (or to values in a different sub form). The form is displayed as datasheet.
You enter the values you need, all of them are from different linked tables,
and when you go the the next record your values had disappeared and instead you get totally different values!
For example:
the value should be "style" in the outside form
so for the style "myStyle" on the Parent Form the values in the sub form should be:

Bold 5%
Italic 10%
Normal 30%

But when you insert them they're seems to be taking from an existing style somewhere else. When you look in the table in the database, the values had entered correctly, it's just that the display is wrong.


The solution:
Add the id of the linked value to the subform, just hide it. That sort the mess out!

Environment:
Ms-Access 2003, Linked SQL tables.

Has google docs lost their mind????

Goggle Docs is my favourite word processing application. Simple: I use it for all of my list of changes in the database. Whatever I need to do, I just type it in. I make sure nothing personal/confidential is in there, and I've found that this is the best way to log changes or to write notes to myself that I can access from home or from work.
Today I tried to create a new document for an article that I would like to write, and when I pressed "create new" there was only "from template". Well, I would like to use my beloved "empty document". Oops, you can't do that. Why? Why? Why? Will I have to give up Docs? Will I write my article with pen and paper? Will I be able to read my handwriting afterwords? And why can't I "give feedback"? That's very unlike the expected behavior from a Giant, is it?
I will let you know the answers, whenever I have them...

String or binary data would be truncated

Scuffling with ‘String or binary data would be truncated’

While the above post was absolutely right about this problem, origins & solution, mine was a bit different:
The solution lay not in the table, but with the table audit. While the description column was defined as [varchar (30)] in the original table, in the Audit table it had to be settled with [Varchar (20)]. Obviously, it wasn't enough: you give the user room to write more in the description column, and they'll use it.

(Yes, of course I had to put the description in the audit table, as the definitions of what's being audit changes all the time)

The order of columns in a Access Query

If you write a query in Access using the design view, and then move to "datasheet view" and change the order of the columns, the columns' order stays the way you've closed it.
But if you try to "Export to Excel", the order of the columns will be the same as it was defined in the design view. You need to change it in the design view in order to get it in the order you want.

summing up decimals

I've just created a view that summs up percent value, that is saved in my SQL back-end as Decimal (5,4).
It resulted in the datatype (DECIMAL (38, 4)). Those 37 non-necessary digits were read by the Access database as Text, not number. If the number is treated as Text, then that causes ceveral problems to the access database: for example, it cannot format it as percent.
Since I don't really need those 37 digits, I've changed it to Decimal (6,4) (with an extra digit just to be on the safe side ; the sum shouldn't anyway exceed the 100%) and re linked the table. That sort this problem out.

Enter Parameter Value when exporting to Excel

The following problem is quite common, I believe, but without a simple solution.

I've create a query which depends on a parameter from the end user (being entered via a form). It runs beautifully.

But on "Export to Excel" (a command that does DoCmd.TransferSpreadsheet) it asks for the parameter value again.

The solution:

dictate the parameter to the query.

That means that instead of placing the parameter in the query, and placing the parameter there (Let's say, SELECT quantity, ..., FROM orders WHERE quantity > Forms!msg_quantity! txt_quantity)

You would place it in the VBA code like that:

Private Sub CreateQuery()

Dim qdf As DAO.QueryDef

Dim sSQL As String

sSQL = "SELECT quantity, ..., FROM orders WHERE quantity > " & Forms!msg_quantity!txt_quantity

Set qdf = CurrentDb.QueryDefs(Me.Form.Caption)

qdf.SQL = sSQL 'This saves the query

qdf.Close

End Sub

It is slower, of course, but if the client really needs exporting to Excel then the client can get it without the unusable "enter parameter value" text box. Trying to hide the text box didn't work in this case.

This way the parameter value is known to the query on export time.