I wrote a little SQL command to correct a field in a table. Since it was so small (and maybe I got a little arrogant) I didn't run it even once, and just put it into an update package for a different user.
Dim SQL As String
Dim rs As DAO.Recordset
On Error GoTo errhandler
SQL = "UPDATE Table1 SET Name = 'Calender' WHERE Name = 'Clalender'"
CurrentDb.Execute
errhandler:
Exit Sub
That's why I didn't notice it should have been
CurrentDb.Execute (SQL)
When the user started this command, Access said something like "Critical Error" and closed.
How come the error handling didn't catch that error? And why didn't Access tell me there was something missing when I wrote it? Usually it's quite pedantic about that.
The statement
CurrentDb.Execute
will not compile.
Compile error: Argument not optional.
Your victim ;) must have hit the error when they tried to run the code, which triggered an "on-the-fly" compilation. Error trapping in your code would not handle that because your code never got a chance to run (because it wouldn't compile).
In other words, Access would have gotten all pedantic on you if you had tried to run (or at least compile) your code.... :)
Try to compact and repair the database.
If that does not work, create a new empty database and import all the objects from the problematic database. Perhaps, you can import a few objects each time to determine which is the corrupted object (if any. Sometimes Access have this behavior and there isn't any bad object).
Related
I am trying to insert 2 values from variables into a table via SQL, the code finishes without error but the entries are not showing up in the table.
I tried executing the code within the immidate window but that gave me an error about my brackets (Don't really know how to enter the prompt properly there), so I changed my query from having variables to having set values to insert, but it still does not work nor does it give an error.
I made sure I had no "On Error" in my code and tried to build in an error manually. Syntax errors are shown as usual so I am assuming that everything is fine with error messages.
'Table Columns: ID, ProjectID, Versionnumber
SQL = "INSERT INTO tblVersion " & _
"(ProjectID, Versionnumber) " & _
"VALUES (1, 'v3.0');"
Currentdb.Execute SQL
I expect the Value to be shown when I open the table. Instead, nothing happened at all.
CurrentDb.Execute doesn't raise all errors by default. It will just silently fail, without letting you know the query was unsuccessful, independent of any On Error statements.
As far as I know, all errors that can be generated at compile time (syntax errors, invalid table names or field names) do get raised, while run-time errors (violated constraints, duplicate primary keys, etc.) don't get raised.
To get all errors, use dbFailOnError. This will also cause the entire query to fail if a single operation encounters an error (e.g. one row violates a constraint), while without it only the failed operation won't go through.
So, in summary, use this:
Currentdb.Execute SQL, dbFailOnError
I have a passthrough query in an Access 2010 application, which I'm using to call a stored procedure on a SQL Server backend. The stored procedure takes a parameter that I need to make dynamic. The problem is this:
Execute spMyProc 'userName' works as expected.
Execute spMyProc getUserName() generates a "syntax error at ')'" message.
Is it possible to use a function as a parameter in a pass-through query?
Also, I should note that I'm migrating a complex Access application to SQL server, and I'm really not well-versed in what I'm doing. Any suggestions on things I'm doing incorrectly will be gratefully received. This particular question is rising from an attempt to change the Record Source of a Form from a simple select statement in the Record Source property to something that can be run on the server.
You can use this code:
With CurrentDb.QueryDefs("MyPass")
.SQL = "exec spMyProc '" & getUserName() & "'"
.Execute
End With
Because getUserName() is a local VBA function, then you need to pre-evaluate the actual string sent to SQL server. As above shows using a saved pass-though is "handy" since you don't have to deal with connection strings etc.
I'm working on a desktop-application, database, webserver-access combination which someone wrote some years ago. My task is to do some optimications/refactoring and to introduce new features to this application(s). I have not much experience in developing web applications, so it's quite difficult for me to find a solution to my problem described below, hoping someone can help me.
The webapplication is written with ASP and VBScript having some small javascript functions which do not affect my question. It uses ADODB for communicating with the database.
The database is a MS-SQLserver 2008 database.
The desktop-application is written in C++/CLI using the .Net built-in features for communicating with the database. With this application everything is working.
For introducing some features I need to add new columns to tables in the database. Inserting and updating of the main table is done with stored procedures. I added a column named "internal" of type "bit":
ALTER TABLE maintable
ADD internal bit
GO
I altered the stored procedures for inserting and updating, just by adding the internal column and a parameter for it. I made only these changes:
1x line for the parameter
added internal in the column and values list for the insert
added setting internal column with parameter for the update
In the vbscript which already was working before any changes I added the code for appending the value for internal as new parameter (its the same for insert & update):
sqlcmd.Parameters.Append(sqlcmd.CreateParameter("#internal",11,1))
sqlcmd.Parameters("#internal")=0
After these changes the update und insert procedures of the vbscript stopped working. I tried several datatypes for the parameter and also changing the column (different name, different datatype). Nothing worked. The stored procedures themself are working fine when executed directly in the database and also when used by the desktop-application.
I started to debug everything with printing some debuginformations ect. I added try/catch in the stored procedures and a outparameter to get some errors according to this answer and I selected all input-parameters into a varchar outparameter. This caused the next strange results.
While updating "worked" (because the stored procedure didn't cause a database error and I got the input-parameter informations which didn't show wrong values, but no update was performed) inserting didn't workin any way. My tracing outputs where printed till the sqlcmd.Execute, this line seems to crash since the trace outputs after this line wheren't printed. As long as I did not use the outparameter the insert itself didn't work, but all trace outputs got printed. I tried to retrieve information about a possible database error directly after the execution of the code with:
DECLARE #ErrorVariable INT;
SET #ErrorVariable = ##ERROR;
SELECT #ErrorVariable AS ErrorID,
text
FROM sys.messages
WHERE message_id = #ErrorVariable;
GO
There was no database error.
Everything works fine from the desktop-application side. As mentioned the stored procedures executed directly in the database will work properly. I suppose the the error is somewhere in web-scripting-stuff. So now here are the concrete questions:
Why would the stored procedure not work (properly) when adding a new column to the database (it is there) and no syntax errors in the stored procedures or vbscript?
Why the sqlcmd.Execute stops working when adding a outparameter to the insert stored procedure? The try-block in the stored procedures includes everything between "AS BEGIN" and "END" having the catch-block directly before "END". Syntax is here also correct.
try to catch the error at the asp end.
On Error Resume Next
sqlcmd.Execute
for each objerr in yourconnection.Errors
Response.write objerr.Description & "<br/>"
next
On Error GoTo 0
Please check this link:
ADO Connection Object Errors Collection
I am trying to keep a copy of an activity table synchronized between a SQL Server Express table and the production Access version. In other tables, I am able to wipe the contents of the SQL Server table, and insert the whole mess back in to capture all of the changes. However, when I attempt to do that with this table - I get the information - but the Autonumber field increments from the last unused number from the previous iteration. After a dozen or so 'sync' operations, I am dangerously close to running out of autonumbers for this field.
I have tried issuing the 'DBCC CHECKIDENT' from the Microsoft Access front end application, which throws an error that the statement didn't start with SELECT, DELETE, PROCEDURE, DROP, ALTER or something like that. This command DOES work when issued from the SQL Server management console (a tool I do have access to in the current test environment, but will NOT when the application goes production).
I then tried the 'TRUNCATE TABLE' query using the DoCmd.RunSQL command and it threw the error that the operation isn't supported on linked tables (approximately). This table is linked to the Microsoft Access front-end (the back end table is on SQL Server Express).
So, for a quick summary:
Front End is an Microsoft Access VBA application
Data is stored on SQL Server Express on a remote machine
Data tables are linked in the front end application
I will NOT be able to use SQL Server Management Console commands when this application goes production, it needs to run it's housekeeping on it's own.
DoCmd.RunSQL and CurrentDB.Execute do not seem to allow the use of the TRUNCATE TABLE -or- the 'DBCC CHECKIDENT' command.
Both of the aforementioned functions -DO- work when issued from the SQL Server Management Console - see above as to why this isn't a viable option.
-ALL- other tables behave the way I'd expect them to besides this one, resetting their indentity fields as appropriate.
-- Edited 08/08/2011 # 15:08 --
Alright - I have tried a number of attempts at a VBA-based pass-through query, all resulting in an ODBC -- call failed error. Here is the code for the module I created to handle pass-throughs (borrowed the code from dbforums.com):
Function RunPassThrough(ByVal ConnectionString As String, ByVal SQL As String, Optional ByVal QueryName As String)
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb
Set qdf = dbs.CreateQueryDef
With qdf
.Name = QueryName
.Connect = ConnectionString
.SQL = SQL
.ReturnsRecords = (Len(QueryName) > 0)
If .ReturnsRecords = False Then
.Execute
Else
If Not IsNull(dbs.QueryDefs(QueryName).Name) Then dbs.QueryDefs.Delete QueryName
dbs.QueryDefs.Append qdf
End If
.Close
End With
Set qdf = Nothing
Set dbs = Nothing
End Function
As such, I need to specify a connection string to the database; all of the following have failed:
strConnect = "ODBC;DRIVER={SQL Server};SERVER=ENV980-067\ENVIRON_TEST;DATABASE=instkeeper_test;Uid=<my username>;Pwd=<my password>;"
Result: Run-time error ODBC -- call failed (error #3146)
strConnect = "ODBC;DRIVER={SQL Server};SERVER=ENV980-067\ENVIRON_TEST;DATABASE=instkeeper_test;TRUSTED_CONNECTION=YES;"
Result: Run-time error ODBC -- call failed (error #3146)
strConnect = "ODBC;DSN=instkeeper_beta;"
Result: Asks me for the Data Source Name, once specified with the Data Source administration panel, I get Run-time error ODBC -- call failed (error #3146)
strConnect = "ODBC;Server=ENV980-067\ENVIRON_TEST;Database=instkeeper_test;User ID=<my user name>;Password=<my password>;Trusted_Connection=False;"
Result: Run-time error ODBC -- call failed (error #3146)
-- Edited 08/08/2011 # 16:41 --
MORE failures on iterations of the connection strings, I am officially out of ideas on how to make this beast work. After trying the previous - now any pass-throughs made with the interface fail after asking for a DSN. No repair is possible, they have to be restored to call on the linked tables and ran through JET.
strConnect = "ODBC;DATA SOURCE=instkeeper_test;"
Result: Run-time error ODBC -- call failed (error #3146)
strConnect = "ODBC;DRIVER=SQL Server;SERVER=ENV980-067\ENVIRON_TEST;"
Result: Run-time error ODBC -- call failed (error #3146)
strConnect = "ODBC;DRIVER=SQL Server;Server=ENV980-067\ENVIRON_TEST;Database=instkeeper_test;User ID=<my user name>;Password=<my password>;"
Result: Run-time error ODBC -- call failed (error #3146)
In the SQL Server side, you can
Use another DBCC command
DBCC CHECKIDENT ('MyTable', RESEED, 1)
Or use TRUNCATE TABLE...
If the table contains an identity column, the counter for that column is reset to the seed value defined for the column. If no seed was defined, the default value 1 is used.
So you'd run
TRUNCATE TABLE MyTable
I went through all of my code, and checked with a local VBA expert who pointed out that I had made an error in the naming of my tables while attempting to do a pass-through query. I, basically, was referring to the table by the name it possess as a link in my front-end, and not the actual table name it possesses in SQL Server on the back end.
The following connection string, once this was corrected, worked:
strConnect = "ODBC;DRIVER={SQL Server};SERVER=ENV980-067\ENVIRON_TEST;DATABASE=instkeeper_test;TRUSTED_CONNECTION=YES;"
This, then, allowed me to execute the TRUNCATE TABLE command on the remote table, and execute a DoCmd.RunSQL statement to repopulate the table from the production source.
The end result is that when the option is selected to update the Activity, it will purge the contents of the remote table, then read the contents of the production table into the test table for use while resetting the autonumber.
I found out an easy way of doing that trought a SQL query written in Access, at the SQL View!
Check it out at:
http://answers.microsoft.com/en-us/office/forum/office_2003-access/reset-autonumber-in-access-table-automatically/66cbcfed-5cbe-40f6-b939-9aea8bbea2de
Write this:
ALTER TABLE YourTable ALTER COLUMN YourField COUNTER(1,1)
With respect to below macro. Which VB Reference setting I have to do for run this macro.
As I got error "Run-time error '-2147217900 (80040e14)':
Syntax error in From clause.
Updating MS - Access fields through MS-Excel cells
kindly guide.......
To use ADO stuff you have to add the below to your references:
Microsoft ActiveX Data Objects x.x Object Library
As for the syntax error, perhaps pasting some code and telling us which line the debugger says is erroring out on would help. My initial guess is some sort of select statement that is selecting something that doesn't exist -- but without code/intent/example data it would be hard to pinpoint.