02-10-2020, 09:57 PM
(This post was last modified: 02-10-2020, 09:57 PM by SorenJensen.)
Hi mrSpock,
I agree it would look a little ugly, and I'm afraid I'm too tidy a person to accept that. With +20 forms, and still a few to be added, with about half of them having a datamodule, and on each datamodule from 3 to 7 ADOQuery or ADOStoredproc components (one for each table being accessed), it would be too many components in one place.
I have now moved all components back to their original datamodule, and have only one DB connection in the project, placed in UserSession. Each datamodule, mostly one for each of the forms where I have table access, are being created in the the form it belongs to, in that forms FormCreate event. And all the ADOQuery and ADOStoredProc components in the datamodule in question, have it's connection property set to UserSession.DBConnection, it the datamodules onCreate event. Just as I had it from the beginning.
So now the only real difference to my original project is that ALL local vars are moved into the Form class wrapper, in the Public section. And those few procedures I had as local, without a formname in the header, have been given a formname header and has been moved into the public section as well.
All nice and tidy and everything in it's right place. And looking back, I realize I could have saved a lot of hours of trial and error, and frustration and anger and..and... had I just remembered the vise words I once got. Do not have any defs outside the form class definition. That area is no go, it's dangerous, it's burning your data. Worst part is that I have been reminded about it so many times those past days by you guys, and still I did not see the light..... I'm happy the dark hours are behind. Bright light lies ahead.....
To Alexandre: I have now tested it over and over again and have no troubles what so ever, so my request for confirmation about whether it is the way of doing it, no longer stands. Whether it is right or wrong is not so important anymore. What is important is that it works, and so far my tests have failed to break it. You are of course very welcome to comment and hand out wise words. I will look forward to every bit of it, and try to remember it for the future......
Regards
Soren
I agree it would look a little ugly, and I'm afraid I'm too tidy a person to accept that. With +20 forms, and still a few to be added, with about half of them having a datamodule, and on each datamodule from 3 to 7 ADOQuery or ADOStoredproc components (one for each table being accessed), it would be too many components in one place.
I have now moved all components back to their original datamodule, and have only one DB connection in the project, placed in UserSession. Each datamodule, mostly one for each of the forms where I have table access, are being created in the the form it belongs to, in that forms FormCreate event. And all the ADOQuery and ADOStoredProc components in the datamodule in question, have it's connection property set to UserSession.DBConnection, it the datamodules onCreate event. Just as I had it from the beginning.
So now the only real difference to my original project is that ALL local vars are moved into the Form class wrapper, in the Public section. And those few procedures I had as local, without a formname in the header, have been given a formname header and has been moved into the public section as well.
All nice and tidy and everything in it's right place. And looking back, I realize I could have saved a lot of hours of trial and error, and frustration and anger and..and... had I just remembered the vise words I once got. Do not have any defs outside the form class definition. That area is no go, it's dangerous, it's burning your data. Worst part is that I have been reminded about it so many times those past days by you guys, and still I did not see the light..... I'm happy the dark hours are behind. Bright light lies ahead.....
To Alexandre: I have now tested it over and over again and have no troubles what so ever, so my request for confirmation about whether it is the way of doing it, no longer stands. Whether it is right or wrong is not so important anymore. What is important is that it works, and so far my tests have failed to break it. You are of course very welcome to comment and hand out wise words. I will look forward to every bit of it, and try to remember it for the future......
Regards
Soren