I have a use case where I have a customer table which joins with a couple of other tables. It’s a many to one relationship so joining with these two tables will result in over 100+ rows for each customer. The SELECT statement with over 10000 customers doesn’t perform well.
I was wondering if there is a way to loop over each customer, append the result of the SELECT statement and then provide the output in a MySQL stored procedure. This can be done using a CURSOR and a temporary table but is there a way to do it without a temporary table?
I've a list of records (in excel) which I want to lookup in SQL table to find their entry date in table.
For example I've name of 200 customers in an excel sheet which are also in my SQL table but there are many others as well. I want to compare those users in table and find their date of joining the table i.e the date they were added to the table.
Do you have any column such as "customer_id"? If not, create it in the tables as it will make it easier for you to select and join tables. You can use the alter table statement to add the new column. After adding the columns, join the tables and use the select statement to find the required record.
You must have a key to bind those data. Any other way can be dangerous linking these informations. Maybe, the way is adapt your application or excel to provide this bind between the data.
I have an existing sql database which has 2 columns of data (part and variant), another one of our systems uses sql in a different table in the same database but columns are (part and type), how would i merge the two in a datagridview (part, variant and type) using the part to do the select statement in a way to pull the other two bits of info and include them in the same datagridview. In vb.net
Cheers,
Pete
My guess would be that you would need an outer join to get the data, assuming there is an unique key and it's "part", for example:
Select part, variant, type
from table1,table2
where table1.part = table2.part;
Assuming that each table is unique and there is no relationship to part, nor a key:
Select part, variant
from table1
UNION ALL
select part, type
from table2;
This is ANSI SQL, so you may have to adapt it to SQL Server syntax, but I think the intent is clear.
Bind the resultset to the DataGridView.
Does this answer you question?
R/
Prescott ....
I'm trying to build an updatable view in Access for a user. Basically, the underlying tables look like this:
Accounts
--------
accountId
accountName
accountHolder
TransactionStatements
------------
statementId
accountId
received
month
year
The user wants a Query (view) that looks like this:
StatementView
-------------
accountName
accountHolder
year
janReceived
febReceived
marReceived
etc...
The SQL to accomplish this is straightforward using a transpose, but the resulting view is not updatable.
I've also tried doing multiple joins explicitly to accomplish this:
PARAMETERS [Enter Year:] Long;
SELECT accountName, accountHolder, year,
FROM ((Accounts a
INNER JOIN TransactionStatements ts1 ON a.accountID = ts.accountID) 'AND month = 1 (This isn't allowed for some reason?)
INNER JOIN TransactionStatements ts2 ON a.accountID = ts.accountID) 'AND month = 2 (This isn't allowed for some reason?)
WHERE ts1.month = 1 AND ts2.month = 2 AND ts1.year = ([Enter Year:]) AND ts2.year = ([Enter Year:])
But once again the result becomes non-updatable as soon as I add the second INNER JOIN. I've looked at this MS help page, but it hasn't helped me figure out the right way to do this.
It suggests Forms as an alternative, but building a custom form in Access appears to be an even more arcane and convoluted process than writing views.
Any suggestions?
Take a look at this very thorough list of reasons why recordsets are and aren't updateable:
When Recordsets Are Always Updateable
A recordset is always updateable when:
It is based on a single table.
It is based on a query based on a single table.
It is based on a query based on tables with a one-to-one relationship.
When Recordsets Are Never Updateable
A recordset is never updateable when:
It is based on a Crosstab query.
It is based on a Union Query.
It is an Aggregate Query that calculates a sum, average, count or other type of total on the values in a field.
It is an Update Query that references a field in the Update To row from either a crosstab query, select query, or subquery that
contains totals or aggregate functions
Note: By using a domain aggregate function in the Update To row of an update query, you can reference fields from either a crosstab query, select query, or subquery that contains totals or aggregate functions.
It is based on a Query that includes a linked ODBC table with no unique index.
The database was opened as read-only or is located on a read-only drive.
It is a SQL pass-through query.
It is a query whose UniqueValues property is set to Yes. (That is, it is a query with a DISTINCT predicate.)
Cartesian Joins (that is, a query that includes more than one table or query, and the tables or queries aren't joined by a join
line in Design view.)
Query based on three or more tables in which there is a many-to-one-to-many relationship. Note: Though you can't update
the data in the query directly, you can update the data in a form
or data access page based on the query if the form's RecordsetType
property is set to Dynaset (Inconsistent Updates).
Calculated fields. Even if the query itself is updateable, if a column in a query is based on a formula, the field cannot be
updated. However, if the other fields in the formula are updated,
the calculated field will automatically update.
Recordsets Are Updateable Under Certain Conditions
Some queries, especially those involved in a Join, will not be updateable under some conditions, but will be under others. In other queries, even if the query itself is updateable, some of the fields will not be. The following are cases of query problems and their corresponding solutions.
Query based on a Join of tables with no Relationship.
•Problem: If a query is based on two or more tables that DO NOT have a relationship established (with Referential Integrity enabled), the query will be non-updateable.
•Solution: Create a Primary Key or Unique Index on ALL of the fields used in the Join on the "one-side" table. To be clear, this means ONE primary key or unique index based on all of the fields, not separate indexes on each field.
In a query based on a Join of tables with a one-to-many relationship (1:M), you might not be able to edit the data in one or more fields.
Join field from the "one" side
•Problem: If you have a 1:M relationship created between two tables, you cannot change the primary key field (used in the Join) of the table on the "one" side of the relationship.
•Solution: Enable cascading updates between the two tables.
New records, if the "many" side join field doesn't appear in the datasheet
•Problem: In a query based on a 1:M relationship, you can create a new record and fill in the fields that come from the "one" side table, but if the join field from the "many" side table is not visible in the query (that is, the foreign key), you cannot add data to the "many" side fields.
•Solution: Add the join field from the "many" side table (ie, foreign key) to your query to allow adding new records.
New records on the "one" side that are duplicates of other "one" side records.
•Problem: When adding a new record, if you try to type into the "one" side fields, you will be attempting to create a new record. Even if you use the same primary key values, it will give you an error.
•Solution: Add a value to the "many" side join field (foreign key) that matches the "one" side join field (primary key) of an already existing record. The "one" side values will simply appear.
Join field from the "many" side, after you've updated data on the "one" side
•Problem: If you are currently editing fields from the "one" side of the relationship, you cannot change the "many" side join field (foreign key).
•Solution: Save the record; then you'll be able to make changes to the "many" side join field.
New records, if entire unique key of ODBC table isn't output
•Problem: This is different than #5 under Never Updateable. In this case, the primary key of the linked ODBC table exists, but is not added to the query.
•Solution: Select all primary key fields of ODBC tables to allow inserts into them.
Query does not have Update Data permissions
•Problem: Query (or underlying table) for which Update Data permission isn't granted.
•Solution: To modify data, permissions must be assigned.
Query does not have Delete Data Permissions
•Problem: Query (or underlying table) for which Delete Data permission isn't granted
•Solution: To delete data, permissions must be assigned.
Conclusion
The causes of non-updateable recordsets are many and varied. Some have solutions and others don't. Hopefully, this list will help you know the difference.
The above is taken, word for word, from the following blog: This Recordset Is Not Updateable. Why?
I felt it was best to copy and fully attribute rather than try to paraphrase, so that all of the information was given.
The first things I suggest you look at might be that your tables have proper indexing and their relationships are set up properly. Those are usually the two things I gun for first, and they tend to solve most of my own "non-updateable query" issues.
I have a table tbls with a field name containing names of tables.
I'm trying to form a statement to get the number of rows of each of this tables.
Should I use a stored procedure or is there a simpler way to do it?
There is a thread that talks about how you can Get record counts for all tables in MySQL database. Using the result, you can constraint the result set to tables specified in the tbls table.