Reestablishing Record Source
- Thread starter MatthewB
- Start date
- Local time
- Today, 12:45
- Joined
- Jul 9, 2003
- Messages
- 17,503
Make backups first!
Isaac
Lifelong Learner
- Local time
- Today, 04:45
- Joined
- Mar 14, 2017
- Messages
- 11,407
Wow, this is a very broad question and a bit difficult to think of how to give the most helpful/responsible answer.
+1 to UG's suggestion.
Also, it might be a good idea to confirm that you have already documented all of the business and process rules before removing those queries.
Even though this shouldn't be, it is all too common for the only place the business rule is documented is by looking at the design/SQL of a query!
Thus, don't remove your queries unless you've documented the process/rules/requirements somewhere, as you won't have a query to look at and remember - "Oh yes - in this case I want to return Nulls because the Accounting department wishes to know if there is an invoice without a payment", etc. etc.
Don't burn down the house unless you saved the blueprints, as problematic as those blueprints might be.
Even with backups, it's a good chance to create logical documentation to support starting from scratch again.
I commend you for recognizing the value of getting the foundation right. Painful but necessary
+1 to UG's suggestion.
Also, it might be a good idea to confirm that you have already documented all of the business and process rules before removing those queries.
Even though this shouldn't be, it is all too common for the only place the business rule is documented is by looking at the design/SQL of a query!
Thus, don't remove your queries unless you've documented the process/rules/requirements somewhere, as you won't have a query to look at and remember - "Oh yes - in this case I want to return Nulls because the Accounting department wishes to know if there is an invoice without a payment", etc. etc.
Don't burn down the house unless you saved the blueprints, as problematic as those blueprints might be.
Even with backups, it's a good chance to create logical documentation to support starting from scratch again.
I commend you for recognizing the value of getting the foundation right. Painful but necessary
- Local time
- Today, 06:45
- Joined
- Feb 28, 2001
- Messages
- 30,495
On the ribbon there is a database tools option that would let you print out what you have. It can be made to list formal relationships. I would use that before wiping the slate clean.
- Local time
- Today, 07:45
- Joined
- Feb 19, 2002
- Messages
- 47,578
Scary question since relationships have nothing to do with queries.
Always work with a backup. Keep in mind that you should be defining relationships BEFORE you enter data. If you create them after you have data in the tables, you will need to correct the data before you can enforce the relationships.
- Local time
- Today, 06:45
- Joined
- Feb 28, 2001
- Messages
- 30,495
Pat, 'scuse me, but when you have relationships, don't the query wizards look at your extant relationships to correctly arrange for JOINs and such?
- Local time
- Today, 07:45
- Joined
- Feb 19, 2002
- Messages
- 47,578
The wizards all make assumptions based on relationships but you can make the joins whatever you want. The only requirement is like data types. So you can join telephone number to SSN or salary to quantity. The query engine doesn't care.
