I have an old access database that I have converted to Office 2010 format and then moved the one data table to SQL. There is only one form that is associated with the one linked table.
Once it was all done I compared the data from before and after and found that all the ≤ had been converted to =. I had mistakenly set the field as varchar so I updated it to nvarchar. I then inserted some corrected data via SQL Server Mgt Studio and all looked good.
The issue is that if I enter ≤ symbols via access they look fine, but once I close and reopen the front end they aren't there. They seem to be being converted to = when access writes to the sql back end table.
My research says that it may be that the ODBC connection is stuffing up the Unicode character, but then other places say it should be fine. I am not doing the update via sql so I can't try the N in front of unicode text.
Any suggestions?
The comment from Gord was right on the mark. When you make changes to the SQL table in the back end Access will not update the linked table. You need to remove it and re-add it.
Just use the same name as before and everything will work fine.
Related
We have a database that is using a SQL Server backend with a MS Access and Filemaker frontend. It has been working fine. I added two fields to one of the tables today, one datetime field and one bit field.
When the table was updated in Access they can no longer edit a field in the records. A Write Conflict error comes up
"The record has been changed by another user since you started editing it. If you save the record, you will overwrite the changes the other user made. Copy the changes to the clipboard will let you look at the values the other user entered and then paste you changes back in if you decide to make chages.
The save Record option is grayed out.
Any ideas what the problem could be?
Is the bit column nullable? MS Access can show those symptoms when dealing with a nullable bit column.
I'm trying to link an ODBC database - which I have no control on - in MS Access 2007 using a Machine Data Source - I don't know if that's relevant, from what I got this means that the access is set only on this computer -.
When I follow the wizard I can select the table but when the time comes to link it I get the error message:
The database engine can't find 'WTD.DATAPOINT_5/1000'. Make sure it is a valid parameter or alias name, that it doesn't include characters or punctuation, and that the name isn't too long
I think that the problem is that one of the field is named WTD.DATAPOINT_5/1000 and that Access interprets /as a symbol of its own.
The thing is that I don't even need the data stored in this column. Right now I don't know which way to go.
Find a way to tell Access that the / is part of the field name. (Highly improbable)
Retrieve only some fields from the table using built-in Access functions.
Set the connection manually using vba and retrieving only some of the fiels. If this is the way to go I would like some pointers as I have no idea where to start.
Solution number 2: use a passthrough SQL query.
Everything is explained in this tutorial.
Solution number 3: I tried to connect directly in VBA. The code bellow works like a charm for other tables but I still get an error for the table containing the problematic field.
Dim ConnectionStr As String
ConnectionStr = "ODBC;Driver={Oracle in OraHome92};Dbq=BLA1;Uid=BLA2;Pwd=BLA3;"
DoCmd.TransferDatabase acImport, "ODBC Database", ConnectionStr, acTable, "MyTable", "NewTable"
I have a SQL Server 2008 database linked to an Access 2010 front end.
Some of the columns are varchar of varying lengths, from 50 to MAX. There is no default value and they can be null.
Recently, any of these columns longer than 255 started causing the write conflict error:
This record has been changed by another user since you started editing it. If you save the record, you will...
I can update other data, including varchar data, in the same row, with no problems and no errors.
This error occurs when I attempt to update the column directly from my table. It also occurs if I update the table programmatically via VBA or through a form.
It looks like this is because the column is NULL in SQL Server, but I've never seen this before with varchar columns. Is this a "feature" or a thing you just have to work around? It just started happening regardless, which is also confusing.
The leading cause of updatability problems in Office Access–linked tables is that Office Access is unable to verify whether data on the server matches with what was last retrieved by the dynaset being updated. If Office Access cannot perform this verification, it assumes that the server row has been modified or deleted by another user and it aborts the update.
There are several types of data that Office Access is unable to check reliably for matching values. These include large object types, such as text, ntext, image, and the varchar(max)(which is in your case), nvarchar(max), and varbinary(max) types.
Coming to your situation,i believe access forms may be bound to the data & produce a lot of locks on records and tables of SQL Server, those locks can prevent tables to be updated.So try to rectify Access forms which are bound to data and that are showing those updateability errors and make them work with unbound data, which allows you to read and update that unbound data to users without creating locks on the database server.
We are using Delphi XE3 together with a TSQLDataSet and a TClientDataset to read a table into memory from SQL server 2012.
The table contains various fields, one of them a blob "varbinary(max)" where we store the content from a text file.
My problem is that we get an error message saying "connection is busy with results for another command" when we do a open on the ClientDataset.
The commandtext is a simple "select * from tablename".
This happens only if there are more than one item in the table. It also happens only if there are data in the blob field (<> NULL).
Everything work fine if we add a second varbinary field to the table. The second field does not have to contain any data.
This is driving me crazy, please help.
EDIT: As a workaround we have simply added a "dummy" varbinary field to the table. Because of this strange behavior, we have come to the conclusion that this has to be a bug in the TClientDataset component. Tried to do the same in a older version of delphi (XE2 SP3) with the same result.
I'm attempting to run a simple statement against an Access DB to find records.
Data validation in the records was horrible, and I cannot sanitize it. Meaning, it must be preserved as is.
I need to be able to search against a string with white space and hyphen characters removed. The following statement will work in Access 2010 direct:
select * from dummy where Replace(Replace([data1],' ',''),'-','') = 'ABCD1234';
Running it from an ODBC connection via PHP will not. It produces the following error:
SQL error: [Microsoft][ODBC Microsoft Access Driver] Undefined function 'Replace' in expression., SQL state 37000 in SQLExecDirect
Creating a query in the database that runs the function and attempting to search its values indirectly causes the same error:
select * from dummy_indirect where Expr1 = 'ABCD1234';
I've attempted to use both ODBC drivers present. ODBCJR32.dll (03/22/2010) and ACEODBC.dll (02/18/2007). To my knowledge these should be current as it was installed with the full Access 2010 and Access 2010 Database Engine.
Any ideas on how to work around this error and achieve the same effect are welcome. Please note, that I cannot alter the database in way, shape, or form. That indirect query was created in another mdb file that has the original tables linked from the original DB.
* Update *
OleDB did not really affect anything.
$dsn= "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\dummy.mdb;";
I'm not attempting to use it as a web backend either. I'm not a sadomasochist.
There is a legacy system that I must support that does use Access as a backend. Data gets populated there from other old systems that I must integrate into more modern systems. Hence, the creation of an API with Apache/PHP that is running on the server supporting the legacy system.
I need to be able to search a table that has an alphanumeric case identifier to get a numeric identifier that is unique and tied to a generator (Autonumber in access). Users have been using it a trash box for years (inconsistent data entry with sporadic notations) so the only solution I have is to strip everything except alphanumeric out of both the field value and the search value and attempt to perform a LIKE comparison against it.
If not replace() which is access supported, what ODBC compatible functions exist that I can use do the same kind of comparison?
Just to recap, the Access db engine will not recognize the Replace() function unless your query is run from within an Access application session. Any attempt from outside Access will trigger that "Undefined function" error message. You can't avoid the error by switching from ODBC to OleDb as the connection method. And you also can't trick the engine into using Replace() by hiding it in separate query (in the same or another Access db) and using that query as the data source for your main query.
This behavior is determined by Access' sandbox mode. That linked page includes a list of functions which are available in the default sandbox mode. That page also describes how you can alter the sandbox mode. If you absolutely must have Replace() available for your query, perhaps the lowest setting (0) would allow it. However, I'm not recommending you do that. I've never done it myself, so don't know anything about the consequences.
As for alternatives for Replace(), it would help to know about the variability in the values you're searching. If the space or dash characters appear in only one or a few consistent positions, you could do a pattern match with a Like expression. For example, if the search field values consist of 4 letters, an optional space or dash, followed by 4 digits, a WHERE clause like this should work for the variations of "ABCD1234":
SELECT * FROM dummy
WHERE
data1 = 'ABCD1234'
OR data1 Like 'ABCD[- ]1234';
Another possibility is to compare against a list of values:
SELECT * FROM dummy
WHERE
data1 IN ('ABCD1234','ABCD 1234','ABCD-1234');
However if your search field values can include any number of spaces or dashes at any position within the string, that approach is no good. And I would look real hard for some way to make the query task easier:
You can't clean the stored values because you're prohibited from altering the original Access db in any way. Perhaps you could create a new Access db, import the data, and clean that instead.
Set up the original Access db as a linked server in SQL Server and build your query to take advantage of SQL Server features.
Surrender. :-( Pull in a larger data set to your PHP client code, and evaluate which rows to use vs. which to ignore.
I'm not sure you can do this with ODBC and your constraints. The MS Access driver is limited (by design; MS wants you to use SQL Server for back ends).
Can you use OLEDB? that might be an option.