|
Alex007 posted:Meet your new friend SQL_CALC_FOUND_ROWS !!! Will you be my best friend? This is news to me and makes my life a happier one
|
#
¿
Dec 21, 2007 22:42
|
|
|
|
| # ¿ May 7, 2024 01:58 |
|
|
I wonder if someone could give me some pointers regarding a table structure for a hierarchical team setup. I am developing a workforce management system for about 2000 employees (using Access). I have the employee side of things set up fine - one employee record to many employee detail records, where employee detail is things like hours, shift pattern, basically anything that changes over time so we can have a historical picture of their employment. Currently these detail records also store the team the employee is in as we want to know that historically too. Where I am struggling is the team structure and the best way to store and manage it. There are about three levels of management and at each level we need to be able to pull results for everything under each span of command. Level one is fine, as there is only one team underneath each low-level manager. At level two, each manager manages around 10 lower-level managers so we need to be able to query information about those 10 lower-level managers and also the members of staff they manage. So on and so forth. I'm not sure if I am Googling poo poo terms or what, but I cannot find practicle examples of how best to do this. Has anyone done anything similar and would you care to share how you tackled this? Thanks.
|
|
#
¿
Feb 16, 2011 23:28
|
|
|
stray posted:I know I'm going to get some poo poo from people here for even mentioning this accursed product's name, but I have to work with Microsoft Access. I'm trying to turn a large Excel spreadsheet into nicely-formatted reports and Access actually does make it pretty easy. Everything works except for one thing. This isn't an SQL question so it is probably better placed elsewhere. Anyway you are going to have to delete any currently linked tables (see DeleteObject) and then link to the new file, the path for which you will have from your File Open Dialog (see TransferDatabase) using VBA.
|
|
#
¿
May 28, 2011 11:16
|
|
|
mindphlux posted:Any thoughts? I can't say for sure without seeing the app but is it maybe because the combobox has focus? I have never used that feature of Access so I can't say for sure. To ensure it does what you want it to do you could look in to the Excel object model and create your own export to Excel function, and add a button to your form. It's really quite easy. My one clue is 'CopyFromRecordset'. I have seen too many people iterate through recordsets (takes forever) instead of using this function which takes a tiny fraction of a second.
|
|
#
¿
Apr 6, 2012 19:13
|
|
|
This is probably a really basic question but I was really doubting myself earlier when planning the schema for a new system. The structure of things is: There is an event (not in the programming sense) which has a unique ID Each event can have 1 to n customers who all have unique reference numbers Each customer can make 0 to n responses to the invitation to the event Each response can specify 1 to n options So, the event table's PK is the EventID The event customers table's PK can be EventID and CustomerID (the customers table is completely separate, this just relates the customer to the event) Would the normal thing to do here be to have the response table's PK being EventID, CustomerID and ResponseID? And then the next increment for the options? Also, the options each have a fixed ID so they are fine to tack on to the PK if this is the route to go down but the responses do not. If this is the route to follow can the responses table's PK be EventID, CustomerID and then a count of responses +1 for ResponseID? Please enlighten me. This is on SQL Server 2008. Thanks
|
|
#
¿
May 17, 2012 22:05
|
|
|
|
| # ¿ May 7, 2024 01:58 |
|
|
Goat Bastard posted:...but then what if you get thrown the additional requirement that each customer can respond multiple times to one event (maybe they're suddenly allowed to decline then attend it, or attend it multiple times for some brain-dead business reason or something). Each customer can response as many times as they want to one event. Sorry if that wasn't clear in my original question. Sorry for being dumb but when it was said earlier that the real world changes all the time. It is the whole basis of the system that the event ID and the customer ID cannot change, and even if they did it would need to be a change rolled out throughout, e.g. each event id would change to the new one and likewise for the customer id. You can't start disassociating customers with their events for example. Therefore. in my eyes, if either change the uniqueness of the key would still be intact.
|
|
#
¿
May 19, 2012 01:47
|
|