Thanks for the explanation and tips. It turns out I just missed the apostrophe when I copied from SQLPlus, so that part was ok. But I changed everything else.
But now I'm getting a different error on line 3:
ORA-00923: FROM keyword not found where expected
I've run stuff like this on...
I'm having difficulty with the below query (actually just a portion of a much large one - thus the structure.)
I am told "invalid identifier" at line 2, allV.AllVoters. However, if I swap the fields, I get the error at line 2 again, this time on allV.AllDate.
Any ideas what is wrong?
SELECT...
true enough IIF would work. I just don't like all those nasty nested expressions! Makes me dizzy. LOL
I wonder, too - would there be any place that these values would be used? Because if so, a table with the categories and values might be better whether SQL or Access, because who would want...
Well, you can do pie charts in access. Check out the wizard under reports, "New/Chart".
However, I personally don't like them. They don't like as nice and tend to be hard to use when compared to Excel. For my users, I provide data that they can export into Excel and then make much nicer...
Correct, Access does not support a case statement. The cleanest "Access" way of doing this would be to have a table containing the possible categories and their values, and then do a sum of the values, grouping by employeeID.
I may be wrong about this - but I think I remember the NZ function being a "if the field is null, provide value1, otherwise, provide value2."
If my memory is correct, SQL DOES accomplish the same purpose - it just needs to be rewritten as the following:
Case When myfield is null then value1...
What I do is provide a table that contains a field of hyperlinks. Then the user can copy and paste the Windows address of the file or folder into the field in the database, and it's linked. Prevents you from having to store the file itself and bloating your table, and accomplishes the same thing.
Have them give you your own database that you have db ownership have. Then have them give you whatever level of permissions is appropriate for those few additional tables. They should be comfortable doing this, because in SQL security settings are pretty straightforward. They can give even...
For that number of people, moving to SQL is a better option. The problem is that with locking/unlocking records and other database issues, Access can end up corrupting the data if things aren't done just right. SQLServer handles all that much better and you won't have a data corruption...
open your database and go to tools/options. Choose the tab for forms/reports. At the buttom there is an option for "use windows themed controls". Check that, and your buttons should be rounded.
On the other hand, if you want to execute the query and then do something with the data using a recordset object in vba, you have the following options:
TYPE 1
Dim rst As New ADODB.Recordset
Dim cmd As New AdoDB.Command
Dim parameter1 as string
Dim parameter2 as string
parameter 1 =...
There are a couple of ways of doing it. Perhaps the easiest is if you are opening a form or report based off of this query, open the properties dialog of the form or report, and under the data tab, put the following in the input parameter row.
@myParameter = [Forms]![frm_1]![txtBox]
In Access you basically just have "queries." In SQLServer, you have views, stored procedures, and functions.
Views cannot take in parameters. Stored Procedures can. Functions return a single value (although that single value could be an entire table.).
The short answer to this - build a...
I think so. you could create a table to hold the values.
And then, on the "on format" event of the report footer, read in the value from the text box and write it to the table.
But report events are a little funny - so I may not be correct about when you can do this. It's what I would try...
perhaps the issue is that an autokey is an integer, not a string. And all the parentheses are confusing to me - I don't think they are all necessary.
You might try this:
Dim myString As Long
Dim strSQL As String
myString = List8.Column(0)
MsgBox (myString)
DoCmd.RunSQL ("DELETE FROM...
lameid - interesting - I had never heard of this, but it makes sense. Unfortunatly, that doesn't answer it either.
The database is in a shared folder that all users have full permissions to. I also turned off compact and repair on close because of some problems we were having if someone...
Unfortunately, we can't give each person their own copy due to network regulations (long story.) And it shouldn't matter because it serves no purpose except reading reports. AND usually there are only 2 people at most opening it, so it shouldn't matter.
But here's the thing - the form is not...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.