I have a database which is split into an Oracle back end and Access front end applications. I tried to migrate the back end over to SQL Server, but when I did this using SSMA I lost functionality on a lot of the Access applications. I don't know where to start to resolve this, I'm thinking maybe there is a mismatch in the syntax? Is anyone able to lead me in the right direction into solving this?
Edit:
I identified the main error came from NULL values when trying to insert delegate names into a form for courses running.
SSMA has thrown up an 'Unparsed SQL' error on the below code:
CREATE OR REPLACE TRIGGER "ISTRAINING"."INSERT_COURSE_DELEGATES" BEFORE
INSERT ON "COURSE_DELEGATES" FOR EACH ROW declare
row_locked exception;
pragma exception_init (row_locked, -54);
begin
begin
select next
into :new.COURSE_DELE_ID
from ISTRAINING.sequence
where tname='COURSE_DELEGATES' and tcolname='COURSE_DELE_ID'
for update of next nowait;
exception
when row_locked then
raise_application_error (-20002,'Database temporarily locked');
end;
update ISTRAINING.sequence
set next=next+1
where tname='COURSE_DELEGATES' and tcolname='COURSE_DELE_ID';
end;
Does this help? I'm sorry I'm just a little lost and not sure what the right question is.
It not clear why issues would crop up. You make no mention of what does not work (you have to improve your question and add some examples of what does not work)
My car is broken does not help at all here.
Given that you had a working application, then all of the work and changes to make access work with Oracle should VERY much apply to SQL server.
In other words, the code changes required are close to identical in both cases.
The only area that would require changes if the application uses pass-through queries. This would mean that such code and quires are written in a 100% oracle SQL syntax as opposed to SQL server syntax.
For liked tables, and reports based on linked tables, then ZERO changes are required.
However, if ADO recordsets are being used, then that’s likely where changes are required.
So first up would be to identify if pass-through queries are used. I would simply check the syntax (simply run them) to see if they work. After the PT queries are addressed, then next up would be to search + scan and look at any ADO code (if ADO was used – we don’t even know this). If no ADO code exists, then few if any changes would and should be required here.
As noted, you not shared more information then that your car is broken – without details of what code or what in a form is failing, then we really have close to zero to go on here.
Related
I've inherited a MS Access database which I should batch-update some data on. Thus, I've created a new query and as a first test tried to get some filtered record list - without success. Access strictly refuses to compile code that contains the LEFT function.
This does compile:
SELECT ColPath FROM MyTable;
This does not compile:
SELECT LEFT([ColPath], 3) FROM MyTable;
Even a simple
SELECT LEFT('Hello', 2);
doesn't work.
I've googled a lot now, and found solutions that either recommend checking the references in the Tools/References dialog in VBA view. There a no missing references in my case. A second solution was to check VBA modules for duplicate OPTION COMPARE DATABASE statements - none in my case.
I then created a brand new database and tried - surprisingly, everything works fine! I now compared the references of the new database to the old one: They are the same.
I'd be happy about any ideas on this...
Sounds like you messed up your references.
In the VBA editor, go to Tools, then References.
The top 2 should always be Visual Basic For Applications, then Microsoft Access ##.# Object Library, in that order (note the priority buttons to change order). Anything else will cause trouble.
Even though you have no missing references, incorrect ones can still cause this issue.
Second to that I'd do the general troubleshooting steps, decompile (Win R, MSACCESS.EXE /decompile, Open the database, hit Debug -> Compile) and a compact and repair. That will cause your entire database to recompile, and if your VBA code contains compile errors, that'll affect any queries calling any function.
I have a couple of stored procedures that are scheduled to run at night because execution times are too long to execute them intraday. Usually that works fine.
However, I (and sometimes others) regularly need to adjust lines. As the whole procedure has well over 1000 lines it has happened that people unintentionally made small syntax errors (forgetting an alias for example).
Is there a way to trigger some kind of error notification (preferably by mail) in case the procedure is not executed completely? I've done some research but could not find anything - so I guess its not possible. Or is it?
Use
DECLARE ... HANDLER
https://dev.mysql.com/doc/refman/8.0/en/declare-handler.html Statement to detect sql errors and then Insert into a table or update an entry
Sending email could be eventually done by user defined functions http://www.mysqludf.org/about.html
But it is not recommended to add functions like email to your database
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 have been charged with maintaining a legacy classic ASP application. The application uses an ODBC system DSN to connect to a MySQL database.
We had to recently update the servers to satisfy some licencing requirements. We were on Windows, with MySQL 4.x and the 3.51 ODBC driver. We moved to a Linux machine running MySQL 5.1.43 and are running the 5.1.6 ODBC driver on the new IIS server.
Users almost instantly started reporting errors as such:
Row cannot be located for updating.
Some values may have been changed
since it was last read.
This is a ghost error, and the same data changes, on the same record, at a different time won't always produce the error. It is also intermittent between different records, as in, sometimes, no matter what values I plug in, I haven't been able to repro the defect on all records.
It is happening across 70 of about 120 scripts, many over 1,000 lines long.
The only consistency I can find is that on all of the scripts that fail, they are all reading/writing floats to the DB. Fields that have a null value don't seem to crash, but if there is a value like '19' in the database (note the no decimal places) that seems to fail, whereas, '19.00' does not. Most floats are defined as 11,2.
The scripts are using ADODB and recordsets. Updates are done with the following pattern:
select * from table where ID =
udpdated recordID
update properties of the record from the form
call RecordSet.Update and RecordSet.Close
The error is generated from the RecordSet.Update command.
I have created a workaround, where rather than select/copy/update I generate an SQL statement that I execute. This works flawlessly (obviously, an UPDATE statement with a where clause is more focused and doesn't consider fields not updated), so I have a pretty good feeling that it is a rounding issue with the floats that is causing a mis-match with the re-retrieval of the record on the update call.
I really would prefer NOT re-writing 100's of these instances (a grep across the source directly finds 280+ update calls).
Can anyone confirm that the issue here is related to floats/rounding?
And if so, is there a global fix I can apply?
Thanks in advance,
-jc
Have a look at MySQL Forums :: ODBC :: Row cannot be located for updating.
They seem to have found some workaround and some explanations as well..
I ran into a similar issue with a VBA macro utilizing 4.1. When upgraded to 5 errors started popping up.
For me the issue was that values being returned to VBA from MySQL was in a unhandled (by VBA) decimal format.
A CAST on the numbers when querying helped to fix the issue.
So for your issue perhaps the ODBC/ASP combination is recording/reading values differently then what you might expect them to be.
I'm working with MySQL 5.1.39 and Visual Studio 2008 and connecting both with MySQL Connector Net 6.1.2.
What I'd like to do is once a MySqlConnection object is created, be able to handle the "event raised" when a field in a specific row in a given table is updated.
I mean, when that value in that table has been manually changed or modified from any other application, I'd like to receive a signal in my opened VB.NET application. Until now, I do it from opened VB.NET application checking that table every X seconds, but I wonder if it could be done in a better way.
Many thanks for your attention and time.
Ideally, there is the SIGNAL construct, which you can use to field SQL logic errors, but that is not available until MySQL 5.5. It would be best to upgrade to 5.5, if at all possible.
EDIT: There isn't really a good solution for this before 5.5. The TRIGGER works for getting the updates, but not for sending them outside of the database. Be careful, though, as this doesn't work if you're updating through FOREIGN KEY actions, such as CASCADE or UPDATE, as TRIGGERs are not called for these actions. So watch out for that.
DELIMITER $$
CREATE TRIGGER my_trigger_name AFTER UPDATE ON my_table_name
FOR EACH ROW BEGIN
CALL my_on_update_procedure(NEW.entry_name, NEW.whatever_else)
END $$
DELIMITER ;
What my_on_update_procedure does is up to you. Your solution is probably the best bet for 5.1.39 (I would not recommend locking due to scalability issues), but 5.5 would give you the SIGNAL construct, which is exactly what you want (so upgrade!).
I never worked with that but I think "TRIGGER" could be what you're looking for.
http://dev.mysql.com/doc/refman/5.1/en/create-trigger.html
My first thought was to use a database trigger to trigger some sort of notification: message through email, MOM or anything else. Googling didn't turn much up though. I found one approach based on notification through locks: linky. Could be a sane approach...
Oh, and in that blog post they also talk about MySQL UDFs which lets you execute arbitary code when triggers fire. Apparently there is libs to various languages. There is also a duplicate question here on stackoverflow. Cheers