Keith Nichols
Registered User.
- Local time
- Tomorrow, 01:09
- Joined
- Jan 27, 2006
- Messages
- 431
Hi Guys,
The application I developed was a couple of steps ahead of my knowledge all the way. As I climbed the learning curve (many thanks to all those kind souls who "Sherpa'd" me along the way) I came to realize that many things had been done the hard way.
Much of the nonsense has been removed but the remaining issue is SQL vs Queries. In a thread I can't recall now, it was suggested that the SQL littered throughout my database could cause problems down the track.
To start, the database works. I am developing release 2 as we speak, but none of the problems with R1 were SQL related.
Secondly, All my tables have the relationships pretty well defined. And here is confusion No.1. When I created tables that had linked information, I would use SQL to show that information in a combo box on data sheet view. This seems to be a duplication of the relationship that is defined in the relationship window, but it works. However, nobody is supposed to use the tables to do anything in the database, it all happens through forms.
All my forms are now based on queries. So, I add a field, such as a combo box, to a form and these have SQL to select the relevant data, sort and filter it etc. A duplication of the duplication?
And a similar situation exists with sub forms, reports etc.
I haven't quantified this, but there are dozens and dozens of these SQL snippets littered about. Most are small beer but a few are rather complex.
So here is the rub, if I convert every snippet of SQL to a query, I might end up with something like 100 queries. With the database window interface as it is, I think this would be unmanageable and would quickly lead to orphan queries. Let alone the horror of trying to name all of them.
It would be easier, and nicer perhaps, if there were some sort of tree view/directory type structure that could group items so that, say, all the queries related to the main dialog form came under a heading with a minimize/maximizes button. But I digress.
Is there any merit in converting the SQL?
Would I see any advantage?
Have I misunderstood something?
It is late at night in Arabia, I have a few coldies on board, and so I must apologize, to any that have got this far, for the ramble. If there are cogent thoughts on the subject, I would be grateful to hear them.
Regards,
Keith.
The application I developed was a couple of steps ahead of my knowledge all the way. As I climbed the learning curve (many thanks to all those kind souls who "Sherpa'd" me along the way) I came to realize that many things had been done the hard way.
Much of the nonsense has been removed but the remaining issue is SQL vs Queries. In a thread I can't recall now, it was suggested that the SQL littered throughout my database could cause problems down the track.
To start, the database works. I am developing release 2 as we speak, but none of the problems with R1 were SQL related.
Secondly, All my tables have the relationships pretty well defined. And here is confusion No.1. When I created tables that had linked information, I would use SQL to show that information in a combo box on data sheet view. This seems to be a duplication of the relationship that is defined in the relationship window, but it works. However, nobody is supposed to use the tables to do anything in the database, it all happens through forms.
All my forms are now based on queries. So, I add a field, such as a combo box, to a form and these have SQL to select the relevant data, sort and filter it etc. A duplication of the duplication?
And a similar situation exists with sub forms, reports etc.
I haven't quantified this, but there are dozens and dozens of these SQL snippets littered about. Most are small beer but a few are rather complex.
So here is the rub, if I convert every snippet of SQL to a query, I might end up with something like 100 queries. With the database window interface as it is, I think this would be unmanageable and would quickly lead to orphan queries. Let alone the horror of trying to name all of them.
It would be easier, and nicer perhaps, if there were some sort of tree view/directory type structure that could group items so that, say, all the queries related to the main dialog form came under a heading with a minimize/maximizes button. But I digress.
Is there any merit in converting the SQL?
Would I see any advantage?
Have I misunderstood something?
It is late at night in Arabia, I have a few coldies on board, and so I must apologize, to any that have got this far, for the ramble. If there are cogent thoughts on the subject, I would be grateful to hear them.
Regards,
Keith.
