I'm using MS Access 2007 as a front end and have all linked tables in SQLServer 2008 R2 backend.
In a form in Access I am trying to execute the FIND button either in the ribbon or by creating a button on the form with the expressed purpose of looking for records with a specific value in a particular field.
When I complete the entry in the FIND window, I click on Find Next. In some cases, the record(s) is found immediately. In others, it can go for hours only to report that it can't find anything (when I know it should).
The table I am looking in has approximately 99,000 records in it. It doesn't seem to matter whether or not the field is indexed.
Is there something I'm doing wrong, or is Access unable to handle this? Also, is creating a stored procedure with handling multiple search requests and passing the info to Access the answer?
The find methods are known to be slow with ODBC data sources. Here is what the Access 2007 Recordset.FindFirst Method help topic says:
When working with Microsoft Access database engine-connected ODBC databases and large dynaset-type Recordset objects, you might discover that using the Find methods or using the Sort or Filter property is slow. To improve performance, use SQL queries with customized ORDER BY or WHERE clauses, parameter queries, or QueryDef objects that retrieve specific indexed records.
Futhermore, binding an Access form to a record source of 99K records is a performance challenge. Use a query as the form's record source, and design the query to return only one or a few rows.
Give the user an option to choose a different set of rows, and modify the form's record source property to reflect the user's choice.
This depends on the type of search you need and on the data type of the column (field) to be searched. For example, if I have a text data type in an indexed column and I search using Start of field or Whole field, it will be quite fast, however, if I search for Any part of field, it may well fall over. In other words, if Access can use an index for the search, it will work, even on quite a large table, otherwise, you may be best with a stored procedure, though I doubt that will be fast without an index, either.
Related
I have a query which joins a few tables. The query asks for a parameter when it is run. Then it displays a few columns/fields from its results, the other fields (like, the entered parameter and other fields that are common to all rows) are hidden. I'm trying to create my first Access report based on this query and I'd like to use some of these hidden fields as a record source for text-boxes/labels but I've been unable to do so. Those fields don't appear in the list of possible record sources.
I've tried the Add Existing Fields button and selecting the field I want from Fields in related tables but when the bound textbox shows up in the report with an error like Invalid Control Property. No Such Field in the Field List which I think means the fields are still invisible to the report. Would appreciate any help getting this done.
The answers is to edit the query and include the missing columns so that they are available to the report.
For non-selected query columns, the use of the word "hidden" is misleading. The way that SQL works--even beyond SQL in the overall concept of datasets--is that only subsets of data are requested in a query. If certain columns are not selected in a query, they are plainly and simply NOT available in the resultant dataset.
It may be possible to re-aquire the excluded columns with another query, but that still does not imply that missing columns were just "hidden". In the case of a subsequent query to get different columns of data, the database engine must re-analyze the new query, re-read the data, then compile the data from the new set of columns to be returned in a completely new subset of data. It is a complete round-trip process that is much more involved than just un-hiding the data.
Forms and reports are completely different types of objects that can mark fields as "hidden", but a query is not the same despite being displayed in a datasheet. Objects like Access Forms and Recordset objects in (VBA) code are designed to hold subsets of queried data, so they are able to temporarily hide (or ignore) or un-hide certain fields without re-querying the database. (Technically an Access Form has its own Recordset object for holding and managing queried data.)
Even though Access is "self contained" with both database and user-interface elements, it is still primarily a standard RDBMS (Relational Database Management System). The principle idea in efficient data handling of an RDBMS is to get only what you need for the current operation. Consider that SQL can be used to query data from a remote server. Even Access can get data from and update data on SQL Server, for example. If data fields were only "hidden" when not included in a query, that would imply that the entire database (or at least an entire table) would be passed back and forth, and that the only thing hindering getting at any column would be "making it visible" as though it is actually immediately available. That would be terribly inefficient both for memory and for remote communications.
I am having some trouble creating a database in Microsoft Access. I have a series of criteria in the same row of a query, many of which look like the following
>=[Forms]![Form1]![Tensile_min] And <=[Forms]![Form1]![Tensile_max] Or Is Null
If I close then reopen the database, Microsoft Access reformats the query to a logically equivalent set of permutations using multiple rows.
The criteria go from this to looking like this, which creates a set of criteria so large it crashes the database. Is there a logical equivalent of the code included above that I can write, which will not reformat?
Thank you for your help.
You could start with:
Is Null Or Between [Forms]![Form1]![Tensile_min] And [Forms]![Form1]![Tensile_max]
If no success, then
Between Nz([Forms]![Form1]![Tensile_min], [YourFieldName]) And Nz([Forms]![Form1]![Tensile_max], [YourFieldName])
Further, do specify both [Forms]![Form1]![Tensile_min] and [Forms]![Form1]![Tensile_max] as parameters to free Access from guessing the data type of these.
Hello helpful internet strangers. I have created a fairly simple database for a client that has one main entry form and a search form that uses unbound text boxes for searching around 15 fields.
Details are below, but here is my problem: When I add new records and use the search form all the fields work as expected and return the correct results in the datasheet. When I sent the database to the client and they add new records, they are not returned in the search. I had them save the database with their records and send it back to me, and I confirmed that when I search for the records they added (I can see the records in the table) they are not returned in the search. If I add new records to the copy they sent me back, my records do appear in the search.
I created the database in Access 2013 on a Windows 8 machine. The client is using Access 2010 on Windows Vista.
The field types are text, dropdown and date. The dropdowns are all based on lookup queries so they store the id number in the main info table and pull the name value from the query. All of the fields in the search query are written to allow nulls, including the date range searches. And again, all fields test out correctly on my machine when I enter the records.
I went on site and compared settings and nothing jumped out at me except the different versions. I also watched the client enter new records and she didn't do anything 'wrong' or unusual. When I try to do a save as 2007-2010 it says I am using features that won't allow for that, but for the life of me I can't think of anything like that since this is really a very straightforward design.
I'm going to do a package as executable, but am highly doubtful that will help. Any insights?
Thanks in advance.
A few things. Most important - always, always develop in the earliest version of Access that the system will be used with. So, you need to rebuild, using Access 2010, period. Try creating a new blank database (in 2010) and importing the objects one (or a few) at a time. Make sure the system is split. One file for the FE (forms, queries, reports, code, etc.) and one for the BE (tables only). Make sure that the Filter On Load property of all forms is set to No. If the recordsource for the form contains a where clause, make sure that the newly entered records meet the criteria for the where clause.
I have a SQL Server that is ODBC into my Access which is being utilized as my front end. I created a column in SQL with a BIT data type and created a checkbox with the yes/no data type that uses my SQL Column as its control source. When I go into my form and try to change anything in there and update my tables, I get a writing error and it wont let me append the updates I'm trying to make. As soon as I delete the bit data type, and the check box, then I am able to again append information to my form. Does anyone know a solution or a way I could utilize the Boolean check boxes to report to my SQL Database so that I could track progress of an order, but still be able to append my records? Also if anyone knows why this is happening I would appreciate the information just for my own notes and understanding.
this image shows the column created in SQL Server
This image shows what it looks like in the ODBC table in Access
This image shows the control source I picked which is from a query that utilizes the names of the form comboboxes, text boxes, and hopefully check boxes
This is image shows what happens after I try to update and and close
Thanks
haven't done this for a long time, but the problem could be related to the numbers that are stored. yes/no in access = -1/0, in sqlsrvr = 1/0 (or similar). you could use an INT field in sqlsrvr which will then store whatever access sends (-1 or 0), or keep the BIT but don't use yes/no in access - create a custom yes/no table where yes=1 and no=0 (or whatever BIT needs) and use the custom table as a lookup table for that field which, when updated will send the appropriate value. hope that's all relevant and makes sense.
So I have been messing around with this and after a few other problems running through SQL, Cabinet Vision (our drafting software with a ancient access database) and crystal reports I came to realize that Access cannot accept null values.
So in my SQL Bit data type column I set the default value as 0 and didn't allow nulls. now it records all my check boxes as true or false. and I no longer have a write conflict.
This most commonly arises when a db is developed in Access and at some later date the tables are exported via ODBC to SQLServer. The Checkbox controls on the Access forms were probably placed there using the 'Available Fields' button on the Access 'Design' ribbon. Before getting into complicated solutions with T-SQL modifications to metadata etc, try simply deleting the checkbox control from the problem Access form. Insert an unbound checkbox to replace it, then use the the Properties dialog to set the relevant SQLServer field as the control source for that checkbox. Usually works.
I'm trying to work at getting the same information from a couple different sources but have hit a wall in trying to use NotesSQL and SQL 2008. What I am trying to do is to retrieve info from a couple different views on Domino servers. One view is a default view, the other is a created one.
One method I have used is Powershell, where I get the database, then select the view, get the first document & then iterate through the rest of the view grabbing fields that I need. The view I have selected is the People view.
I was trying to replicate this same thing using SQL 2008, using the NotesSQL driver, setting up an ODBC connection, and then creating a linked server to that Notes database. I am using the following query to select from the People view:
select * from openquery(MyNotesServer,'Select * from People')
However, what is returned from this view isn't what I am able to see when I use Powershell & then iterate through the documents returned in that view. Powershell shows 100+ columns in it, while SQL only returns 5 columns. Additionally, they're named "_12", "17" etc. Some fields (which may be custom, I don't know) have a meaningful name. Of the fields shown, I can select them by name ("_12", etc) but cannot select anything else. The number of rows (SQL) is the same as the number of documents in the view (Powershell $view.Allentries.Count).
Querying the view that was created (3 fields):
select * from openquery(MyNotesServer,'Select * from MyCreatedView')
returns all the fields in that view, and they are named as they are in the view.
In T-SQL querying the People view, how do you get the names of the columns that I know are there as I discovered in my Powershell script? They don't appear to be named the same thing, so how do you retrieve more than the 5 returned when you select * from the view? I have read through the Notes documentation & examples, but haven't been able to figure out what is mapped to where.
The reasoning behind this is wanting to utilize SQL & a notes.id file instead of running a script. Also, I want to make use of an already existing global view instead of views that may be accessible only to their author.
You can use select * from Person. Person is a form name, not a view name. Notes and Domino are not relational. The NSF file is a document database. The views in it are pre-built indexes that already have an implicit select. I.e., the "People" view selects all documents created with the "Person" form.
The above query bypasses the use of a view and will give you all the fields for all documents created with the the Person form.
Actually, come to think of it, the better query would be select * from Person where type='Person'. That's because the People view in Domino uses type="Person" instead of form="Person" in its selection formula. It is theoretically possible to have a document created with the Person form but with the Type field set to a different value. This variation will insure that you always get the same list that you see in the Person view.
But: In either case, it will be inefficient. The NotesSQL driver will have to do a full database search instead of simply reading the index of an existing view. It's going to search using the Notes formula SELECT Form="Person" & Type="Person". I really cannot recommend this, unless you are querying against a small Domino Directory database.
The best practice is to create a view containing all the fields that you really need, and do your query against that view.
First, in the Lotus Notes documentation, you'll find "columns" when you read about views, not fields.
Second, the columns have configured an option called "Programmatic Name". In that option, you can put an "alias". Lotus Notes puts values by default as "$12", "$17", etc. The thing is NotesSQL changes "$" by "_". That's the reason why you see "_12", "_17, etc.
How do you get the original names? As far as I remember (I don't have Lotus Notes near to make a verification) you can't. But, you can create another view with the columns with the data you need, and put appropiate names. The easy way to do it is copy/paste the view, delete the columns you don't need, and change that you want.