I have been tasked with creating a method to copy the contents of an entire database to a central database. There are a number of source databases, all in Access. I've managed to copy the majority of the tables properly, 1:1. I'm using VBScript and ADO to copy the data. It actually works surprisingly well, considering that it's Access.
However
I have 3 tables that include subdatasheets (to those that don't know, a subdatasheet is a visual representation of a 1 to many relationship. You can see related records in another table inside the main table). When My script runs, I get an error. "No value given for one or more required parameters." When I open Access and try to run the same query that I've written in SQL, It pops up message boxes asking for parameters.
If I use the query wizard inside Access to build the select query, no parameters are required and I get no subdatasheet in the result set.
My question is this: how do I write a vanilla SQL query in my VBScript that does not require parameters and just gives me the data that I want?
I've tried copying the SQL from Access and running it through my VBScript and that doesn't seem to do the trick.
Any help is greatly appreciated!
As it turns out, you need to make sure that you've spelled all of the field names properly in your source query. If you've included additional fields that aren't actually in the source or destination table they'll need to be removed too.
Related
I am currently working on a project of replacing our old access database queries, but on one of them I am not able to view the actual SQL View.
Does anyone know a way to force the view or to export it somehow?
Error causing problem:
The SQL statement could not be executed because it contains ambiguous outer joins.
Note that I can view the Design View without issue but when I right click on the tab and select SQL View is when I get the error.
I did attempt what #LeeMac mentioned below but same error occurs:
EDIT:
This question is not like Ambiguous Outer Joins?
The OP on that question can actually see and edit their SQL.
My issues is that I cannot see or edit the SQL as the SQL View wont open.
Try executing the following VBA code from the Immediate Window (accessible using Ctrl+G) in the VBA IDE (open the IDE using Alt+F11):
?CurrentDb.QueryDefs("YourQuery").SQL
Replace YourQuery with the name of your query.
This should print the SQL code which comprises your query - you can then analyse the SQL to determine the cause of the error.
It's odd this error would arise when merely viewing the SQL content of the query definition.
It makes me think that the query is perhaps referencing a crosstab subquery which is actually the cause of the error, but which needs to be evaluated in order for MS Access to determine the columns available when viewing the design of the query in question.
Try this:
hit ctrl-g, and from immediate window type in this:
saveastext acQuery,"Name of query","c:\test\mysql.txt"
Access ordinarily doesn't allow you to save invalid queries, so it's strange you somehow got into this situation in the first place.
If you can copy the query, you can easily get to the SQL by changing the query to a passthrough query, either through the GUI or through VBA:
Dim q As DAO.QueryDef
Set q = CurrentDb.QueryDefs!Query1
q.Connect = "ODBC;"
Debug.Print q.SQL
Passthrough queries are not validated, so you can freely read and write anything you want as SQL in it.
Note that this is irreversible when done through VBA. You can only change it back to a normal query once you made the SQL valid again. If you do it through the GUI, you can just not save it, though.
I had this problem and the issue was that i had a subquery that calculated fields but did not actually have a table in it. for example it would calculate first and last day of last month which is 2 calculated fields, then it was the first query in a series of queries that were built off it and the last one wouldnt resolve sql as original poster indicated also gave the ambiguous join message as well as query needs input table (which was that first subquery). i put a table with 1 record in it but didnt use the record and it worked.... so it just a needs a table in it.
I have an Access 2010 utility that is designed to query an Oracle DB via ODBC connection as Linked Tables. I created a simple form with two textbox's and a command button. The command button launches VBA code "DoCmd.OpenReport".
The report query Where clause looks like this:
WHERE (((PRODLAW_ITEMLOC.LOCATION)=[Forms]![frm_Qry_ByItem&Loc]![txtLocation]) AND ((PRODLAW_ITEMMAST.ITEM)=[Forms]![frm_Qry_ByItem&Loc]![txtItem]));
the values of txtItem and txtLocation are the user supplied values from the form.
This returns an empty dataset as it is now. If I query a local table, (using a single ODBC query to extract all possible values into a single local table) this method works without any issue other than the 8-10 minutes it takes to refresh the local table. If I replace the query criteria "[Forms]![frm_Qry_ByItem&Loc]![txtItem]" with a simple direct value like "1234" (assuming 1234 is a valid item number), it works without issue.
I've tried to explicitly convert the value of the textbox like "Cstr([Forms]![frm_Qry_ByItem&Loc]![txtItem])" but it made no difference. As this is a query, I can't simply create a breakpoint and examine the properties of the variables so I'm left scratching my head. I've spent hours searching SO and other sites for clues but found nothing related.
Please advise. Thanks!
mfc
I'm getting a little confused about using parameters with SQL queries, and seeing some things that I can't immediately explain, so I'm just after some background info at this point.
First, is there a standard format for parameter names in queries, or is this database/middleware dependent ? I've seen both this:-
DELETE * FROM #tablename
and...
DELETE * FROM :tablename
Second - where (typically) does the parameter replacement happen? Are parameters replaced/expanded before the query is sent to the database, or does the database receive params and query separately, and perform the expansion itself?
Just as background, I'm using the DevArt UniDAC toolkit from a C++Builder app to connect via ODBC to an Excel spreadsheet. I know this is almost pessimal in a few ways... (I'm trying to understand why a particular command works only when it doesn't use parameters)
With such data access libraries, like UniDAC or FireDAC, you can use macros. They allow you to use special markers (called macro) in the places of a SQL command, where parameter are disallowed. I dont know UniDAC API, but will provide a sample for FireDAC:
ADQuery1.SQL.Text := 'DELETE * FROM &tablename';
ADQuery1.MacroByName('tablename').AsRaw := 'MyTab';
ADQuery1.ExecSQL;
Second - where (typically) does the parameter replacement happen?
It doesn't. That's the whole point. Data elements in your query stay data items. Code elements stay code elements. The two never intersect, and thus there is never an opportunity for malicious data to be treated as code.
connect via ODBC to an Excel spreadsheet... I'm trying to understand why a particular command works only when it doesn't use parameters
Excel isn't really a database engine, but if it were, you still can't use a parameter for the name a table.
SQL parameters are sent to the database. The database performs the expansion itself. That allows the database to set up a query plan that will work for different values of the parameters.
Microsoft always uses #parname for parameters. Oracle uses :parname. Other databases are different.
No database I know of allows you to specify the table name as a parameter. You have to expand that client side, like:
command.CommandText = string.Format("DELETE FROM {0}", tableName);
P.S. A * is not allowed after a DELETE. After all, you can only delete whole rows, not a set of columns.
I've hit a bit of an impasse. I have a query that is generated by some C# code. The query works fine in Microsoft SQL Server Management Studio when run against the same database.
However when my code tries to run the same query I get the same error about an invalid column and an exception is thrown. All queries that reference this column are failing.
The column in question was recently added to the database. It is a date column called Incident_Begin_Time_ts .
An example that fails is:
select * from PerfDiag
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';
Other queries like Select MAX(Incident_Being_Time_ts); also fail when run in code because it thinks the column is missing.
Any ideas?
Just press Ctrl + Shift + R and see...
In SQL Server Management Studio, Ctrl+Shift+R refreshes the local cache.
I suspect that you have two tables with the same name. One is owned by the schema 'dbo' (dbo.PerfDiag), and the other is owned by the default schema of the account used to connect to SQL Server (something like userid.PerfDiag).
When you have an unqualified reference to a schema object (such as a table) — one not qualified by schema name — the object reference must be resolved. Name resolution occurs by searching in the following sequence for an object of the appropriate type (table) with the specified name. The name resolves to the first match:
Under the default schema of the user.
Under the schema 'dbo'.
The unqualified reference is bound to the first match in the above sequence.
As a general recommended practice, one should always qualify references to schema objects, for performance reasons:
An unqualified reference may invalidate a cached execution plan for the stored procedure or query, since the schema to which the reference was bound may change depending on the credentials executing the stored procedure or query. This results in recompilation of the query/stored procedure, a performance hit. Recompilations cause compile locks to be taken out, blocking others from accessing the needed resource(s).
Name resolution slows down query execution as two probes must be made to resolve to the likely version of the object (that owned by 'dbo'). This is the usual case. The only time a single probe will resolve the name is if the current user owns an object of the specified name and type.
[Edited to further note]
The other possibilities are (in no particular order):
You aren't connected to the database you think you are.
You aren't connected to the SQL Server instance you think you are.
Double check your connect strings and ensure that they explicitly specify the SQL Server instance name and the database name.
In my case I restart Microsoft SQL Sever Management Studio and this works well for me.
If you are running this inside a transaction and a SQL statement before this drops/alters the table you can also get this message.
I eventually shut-down and restarted Microsoft SQL Server Management Studio; and that fixed it for me. But at other times, just starting a new query window was enough.
If you are using variables with the same name as your column, it could be that you forgot the '#' variable marker. In an INSERT statement it will be detected as a column.
Just had the exact same problem. I renamed some aliased columns in a temporary table which is further used by another part of the same code. For some reason, this was not captured by SQL Server Management Studio and it complained about invalid column names.
What I simply did is create a new query, copy paste the SQL code from the old query to this new query and run it again. This seemed to refresh the environment correctly.
In my case I was trying to get the value from wrong ResultSet when querying multiple SQL statements.
In my case it seems the problem was a weird caching problem. The solutions above didn't work.
If your code was working fine and you added a column to one of your tables and it gives the 'invalid column name' error, and the solutions above doesn't work, try this: First run only the section of code for creating that modified table and then run the whole code.
Including this answer because this was the top result for "invalid column name sql" on google and I didn't see this answer here. In my case, I was getting Invalid Column Name, Id1 because I had used the wrong id in my .HasForeignKey statement in my Entity Framework C# code. Once I changed it to match the .HasOne() object's id, the error was gone.
I've gotten this error when running a scalar function using a table value, but the Select statement in my scalar function RETURN clause was missing the "FROM table" portion. :facepalms:
Also happens when you forget to change the ConnectionString and ask a table that has no idea about the changes you're making locally.
I had this problem with a View, but the exact same SQL code worked perfectly as a query. In fact SSMS actually threw up a couple of other problems with the View, that it did not have with the query. I tried refreshing, closing the connection to the server and going back in, and renaming columns - nothing worked. Instead I created the query as a stored procedure, and connected Excel to that rather than the View, and this solved the problem.
I'm having to support an Access .mdb file that someone else has written. One of the button functions in this .mdb calls out to delete some data in an external MSSQL database. All very straightforward, but this syntax isn't something I've seen before:
DELETE
tblEquipmentConnections.SourceEquip,
tblEquipmentConnections.EquipmentConnectionID
FROM tblEquipmentConnections
WHERE
tblEquipmentConnections.SourceEquip = [Forms]![frmEquipment]![EquipmentID];
Is that any different than this?
DELETE
FROM tblEquipmentConnections
WHERE
tblEquipmentConnections.SourceEquip = [Forms]![frmEquipment]![EquipmentID];
I can't find a case where specifying specific columns does anything - but I don't spend much time in Access, so I'm not sure how different the SQL syntax is...
Thanks!
Specifying the column names makes no difference. It's just an Access thing.
The reason they might be there is because Access used to generate DELETE statements that way (not sure if it still does).
The second form without columns names is obviously preferable.
I think the query has been built directly into Access query editor.
And generally we begin by building a select query. Then we change the query type from "Select query" to "Delete query". Then we display the query source by selecting "SQL Mode" where we copy / paste a sql statement like this one :
DELETE qc_Boxes.idBox, qc_Boxes.idScreen, qc_Boxes.title
FROM qc_Boxes;
This is absolutely redundant. The place between DELETE and FROM is used only when the deletion is performed based on a multi-table condition, but even in this case it contains table names and not field names. Also it can contain * which is also redundant. In MySQL, for example it's an incorrect syntax.