I work for a company where we likely going to update from Access97/2003 to Access2010.
After playing around with a prototype, I have found an issue when using Access 2010 with databases created in Access 2003.
Under some conditions, existing queries/SQL's in Access 2003 will become unusable in Access 2010. Here a small example:
Tablename: Parameters Field names: Number, Value
A query created with Access 2003 query designer:
SELECT Parameters.Value
FROM [Parameters]
WHERE (((Parameters.Number)=100));
this works fine with Access 2003.
In Access 2010 a error is raised: Syntax error in PARAMETER clause
A workaround for the error is to change the view in Access 2003. Here we get rid of the brackets:
SELECT Parameters.Value FROM [Parameters] WHERE Parameters.Number=100;
This will work in Access 2010 but the query remains unchangeable in the designer, because the query designer creates the syntax shown above.
The reason for this error is in fact the use of the reserved word 'Number', which shoudn't be used when you start to build a table or query, but for a migration with hundreds of existing databases, it is very likely or at least a risk to change the Access version without a complete test.
My idea is to write a small program which opens all the existing views and the tables to check if they work fine.
Anyway, dose anybody have a better solution for this, or is there a tool to check MS-Access 2003 databases to be compatible with Access 2010?
Many thanks in advance
Jörg
Parameters, Value, and Number are all reserved words. You may be right that Number is the culprit here; I would have suspected Parameters as more likely to confuse Access in a query.
"For a migration with hundreds of existing databases", first evaluate them with Allen Browne's Database Issue Checker Utility. In addition to the reserved words issue, it will give you an idea of other potential problem areas. Whether those issues will be more troublesome in Access 2010 than in 2003 is an open question.
However I don't see an easy solution for your predicament. You have hundreds of databases with perhaps thousands of tables and queries ... if they routinely incorporate reserved words for table and field names, as well as other object names ... your situation is miserable.
Experiment on a copy of an existing database. Turn on "track name autocorrect" and let it build the object dependencies. Change the table definitions to eliminate reserved words. Then see how much extra work you need to find and fix the items autocorrect didn't do for you. But don't leave autocorrect turned on in any application you release to your users.
Related
I have spent two days researching and try to fix my issue with access form edits. I understand that there may be similar questions out there, but none of the suggestions fixed my problem. Also, my situation might be slightly different.
I'm on Access 2017 and using an access split form that is tied to a linked table that is on sql server 2017. I have an add button that simply adds the record entered and moves to a new record. When I add a record to my form and then try to edit it in the datasheet view on my split form I get a write conflict error.
I've already validated that I have a primary key on my table and that there are no null bit fields.
The other thing to note is that this started happening after migrating from SQL server 2014 to sql server 2017.
One thing I read about and have yet to try because of the "drastic" change it entails is to set the compatibility level of my database to something lower like SQL 2014. This would be a last resort however and would only be to validate what the cause of the error might be.
I've tried everything on this page that is applicable to my situation: http://www.accessrepairnrecovery.com/blog/fix-ms-access-write-conflict-error
What else can I try to resolve this? I'm hoping someone out there has run into something similar.
First this question has been answered 100's of time on stack overflow.
Next up: Your link has nothing to do with using SQL server, so the suggests likely will not help.
The main causes (repeated over and over as solution) when using Access and SQL server are:
Ensure that all tables have a PK defined.
Ensure that any bit fields have a default setup on sql server (usually 0)
Ensure that each table has a timestamp field.
This is important, espeically if you have any floating or "real" data type columns. The Access up-sizing wizard, and the migration tool for Access both by default suggest and will add the timestamp field.
If you missing any of the above 3 issues (that have been repeated over and over for the last 18 years on near every article about using SQL server.
So, you will ensure that you checked above all 3 issues.
After any table changes, you will re-link the access client side.
You then need to test/check if you can change edit data using the linked table directly from access (in table view). if you can edit such data directly, then you are back to testing with your form. If the form still causes a write conflict, then suggests in the article you linked to will START to apply, but not until such time you address and ensure all 3 above steps are issues are dealt with.
The time stamp is often required for a sub form, and also when you have real/floating columns. Due to rounding errors in such computer numbers, then the compare between the two records fail. The adding of the timestamp column fixes this issue since access now does not have to do a field by field compare, but will use the timestamp column (not to be confused with a datetime column) to figure out if record has been changed. Thus adopting this feature even reduces the network chatter from client to server and allows access to determine if server record been changed without having to resort to a field by field compare.
I recently encountered the same error and it turned out to be that I had an active sort on the datasheet view. Once I removed the sort, voila, problem solved! (Nothing like shooting myself in the foot.)
I am trying to export a datatable from Microsoft Access 2016 via ODBC Export to a MariaDB. I have tried:
do a right click on the datatable and choose "Export" --> "ODBC-Database"
then choose the preconfigured ODBC User-DSN
Then I get the ODBC-Call Error:
"ODBC-Driver[...] Data truncated for column 'TotRev' at row 1 [#1265]"
I have tried different codings, as I got other error codes before which were related to that.
I would really appreciate a hint for this solution. The used Database is MariaDB with utf8-mb4 encoding.
Having no familiarity at all with MariaDB - my only suggestion is to export out of Access to a neutral format; either text file or excel.
Then on the MariaDB side - import the neutral file.
I have solved the problem: One specific characteristic with Access is that there exists a datatype currency. This is the problem and so the question is how to get rid of it. Just changing the datatype did not work, as Access run out of memory. The reason is, that Access tries to keep both tables (old datatype + new datatype) in memory.
To solve this problem I found a nice explanation on Microsoft pages. What I did is to follow the hint on this page:
Microsoft forum entry by John W. Vinson/MVP
Here his advice:
"[...]An alternative way to accomplish this task requires a couple of steps but works with any size table:
Rename the table to tablename_old
Copy and paste it to tablename, using the option design mode only
Change the datatype in the new empty table
Run an Append query to migrate the data
It may be necessary to drop and reestablish relationships.[...]"
As I am not familiar with Access here the link to office support how to append an query
Add records to a table by using an append query
I must understand few things about MS access queries, and this is why I'm coming here.
First of all - my task list is written in Latvian (hate that), this is why I can't understand simple things.
Here is my one of tasks: "Make four simple queries, where shows specific, not-specific, number intervals, less than and greater than."
Probably I didn't translated my task correctly, but I can't understand, what does means specific and not-specific query.
This is too simple for me, and this is why I don't get it.
And also I wanted to ask, if there is any SQL commands, which does the same thing like in PHP function substr(). As I tried to use SQL commands, which I use daily writing MySQL queries, does not work in MS Access.
I hope, that some one could help me about this :) Thanks!
/Rob
Here are some references that may help:
Fundamental Microsoft Jet SQL for Access 2000
Intermediate Microsoft Jet SQL for Access 2000
Advanced Microsoft Jet SQL for Access 2000
As for substr, you can use Mid, Left, Right, InStr and InstrRev.
I want to my make a search-statement and query things like this
select * from table where col like '%vkvk%'
But with trial and error I've come to the conclusion that access doesn't work with LIKE or
wildcard operators. Does anybody have some other solutions because I ain't so in to access actually, so I really don't know.
Try:
select * from table where col like '*vkvk*'
Use an asterisk for the wildcard character.
If you want to use some SQL syntax that is like SQL Server, go to your Access OPTIONS and set it for "SQL 92" mode. So far as I know, this does two main things (there may be others):
allows you to use % and _ as wildcards instead of Jet SQL's * and ?.
allows you to use the non-crazy derived table syntax:
SELECT MyTable.*
FROM (SELECT * FROM SomeTable) As MyTable
...instead of the bollixed-up Jet method:
SELECT MyTable.*
FROM [SELECT * FROM SomeTable]. As MyTable
...which has problems with table and field names with spaces in them, since you have to use brackets inside the derived table definition, which breaks the Jet syntax entirely.
As I said, there may be other things it changes, but if you're a SQL Server programmer, you may find it easier to set SQL 92 mode on. On the other hand, most Access help uses Access/Jet/ACE conventions, so you may end up more confused by trying to use it.
EDIT:
Since originally posting this, I've discovered that there are problems with turning on SQL 92 mode in an existing Access application. The two I discovered were:
It changes the list of reserved words, which means that SQL that previously worked with the SQL 89 list of reserved words can break (if it uses a SQL 92 reserved word).
It can break multi-column combo boxes with a hidden first column (which is a very common UI object in Access applications). Specifically, it breaks the Autoexpend/autoselect behavior.
There may be other problems, but I discovered these accidentally when I turned on SQL 92 mode in a client project to test something for SO and forgot to turn it off when I distributed the next update. Fortunately, the problems were quickly detected, and it didn't take me too long to idenfity SQL 92 mode as the cause of the problems.
In short, I don't consider SQL 92 mode in Access to be of use to anybody at all. It's a feature aimed at people who won't be using Access interactively in the first place, seems to me.
like '%kvk%' sometimes work sometimes don't
With Access 2010 with sql server (2008) linked tables
Use '*kvk*'
I tried several "Like" syntax on one request, (I'm using VB.NET and a MS-ACCESS 2010 database), and none of them could get any other result than throwing an exception.Why? I'm not having any idea about that.
I did this workaround that could be useful on some similar cases:
Instead of
SELECT dbFieldDisplayName FROM dbTableName WHERE dbFieldSearchName Like 'A*'
I Used:
SELECT dbFieldDisplayName FROM dbTableName WHERE dbFieldSearchName >='A' AND dbFieldSearchName <'AZZZ'
I'm trying to confirm or deny whether you can define a table column in MS Access 2003 as a set. It seems this is implemented in Office 2007 - you can define a column to have a 'multi-select list' in the query/lookup, but this feature appears to be unique to the new access 2007 file format as far as I can determine.
Worded another way, does MS Access 2003 have the equivalent to the SQL statement:
CREATE TABLE mytable (foo VARCHAR(10), bar VARCHAR(5) MULTISET);
Or is there a clever workaround to achieve something similar? I would accept an answer providing information on any collection constructors in Access 2003.
Are you referring to the Access Database Engine's multivalued data types? If so then yes, these are new to the ACE (2007) version of the engine and are not available in Jet 4.0 being Access2003's version of the engine.
FWIW I tried your SQL in Access2007 using ANSI-92 Query Mode (OLE DB, engine type = 5) and the MULTISET keyword wasn't recognized.
Note you may not need nor want multivalued types. One particular criticism is that Access Database SQL DML expressions service hasn't been altered to take account of multivalued types. Also, see this article Multivalued datatypes considered harmful:
both Suraj [Poozhiyil, the MS Access
Program Manager] and I agree
wholeheartedly that developers do not
need to use multi-valued fields.
People who understand databases
already have a good way of
implementing many to many
relationships and will gain no benefit
from multi-valued fields.
So, my clear and certain advice to
developers is not to use multi-valued
fields. They have nothing to offer us
except potential pain.
UPDATE:
MULTISET is a new datatype officially
beginning with SQL:2003 so I'm
guessing part of the reason for adding
it in Access 2007 is to be fully
compliant with the SQL standard
That's almost amusing. The Access Team have shown no interest in adding SQL syntax that is compliant with any SQL Standard.
[When the SQL Server team were modifying Jet for its 4.0 release they wanted to attain SQL-92 compliance but were prevented from doing so by the Windows team whose components were reliant on some features remaining non-compliant... but that's another story. The Access Team have their own private folk of the code base so they've no such excuse... unless the SharePoint Team now has undue influence? I digress...]
Consider this quote from the document about the SQL2003 Standard:
Values of a MULTISET type can be
created either by enumerating the
individual elements or by supplying
the elements through a query
expression; e.g.,
MULTISET[1, 2, 3, 4]
or
MULTISET(
SELECT grades
FROM courses
)
...Conversely, a multiset value can be
used as a table reference in the FROM
clause using the UNNEST operator.
The Access Team has not added any new expressions nor any operators to the ACE SQL DML syntax. So, no, this has nothing to do with SQL Standards and everything to do with SharePoint.
David W. Fenton: No, [support for
multivalued types] was added in the
ACCDB format (not the ACE, as
#onedaywhen says...)
Consider this quote from the Access Team's own blog:
The primary feature we added to the new
Access engine is support for “complex
data”.
It is definitely an engine feature!