Hi
The tblRacks is just a list of available Racks
When you allocate a wire to a rack that is specific to 1 record.
It is recommended that you do not use Cascade Updates in the Relationship Window.
Hi
The tblRacks is just a list of available Racks
When you allocate a wire to a rack that is specific to 1 record.
It is recommended that you do not use Cascade Updates in the Relationship Window.
You can PM me if you need further help.
Good Reading https://docs.microsoft.com/en-gb/off...on-description
As you say the only time you might want to use the Cascade is if you made an error in the allocation of Racks.
If Rack 1 should have been Rack 12 then you would set Cascade Updates and then change the value in the table.
You can PM me if you need further help.
Good Reading https://docs.microsoft.com/en-gb/off...on-description
As some smart people here have said:
1) Excel presents the data in a useable form. It has limited rules on data.
2) Access manages data and is lousy at presenting data to the human.
3) In a database any one piece of data should only be in one spot.
4) In a database a table should be only a list of one type of thing. These things maybe be physical or connections but should only do 1 thing.
So a cable runs from a port to another port, this gives 1 cable, 2 ports, 2? Locations, 2 devices (hubs?), maybe a wire colour, wire bundle (s), X junction points (for bundles), 2 power sources, Direction (up down). These all would be tables. It is better as you note, to get the design right before creating a DB.
I agree. The main objects of the db should be the devices and their ports (2 tables in o2m rel). Of course, those devices are mounted in racks (one more table). There are several types of devices (Servers, Hubs, Switches, patch panels etc) that should be stored in a lookup table (tlkpDevTypes). Also, there are several kinds, types and categories of ports (e.g. UTP, RJ45 Cat-5e) that dictates the type of the cable that links them. Similarly, there are several kinds, types and categories of cables for a particular link, depending on the environment, mechanic and power demands etc. All those kind, types etc need to be stored in lookup tables.
Finally, the table for the links, should has at least two fields for the ports, as FKs to the tblDevPorts and a field for the corresponding cable, as FK to the tblCables, plus the directly related to the link.
Practically speaking, I suggest this schema:
I may be a bit late, I did a db a long time ago to track cables and what equipment they attach to.
It got quite complicated, and I don't remember or have access (pun intended) to the old database that I used.
Here are some ideas for tables (as best as I remember back 25 years):
LocationType = offices, phone or coms rooms
Location = LocationType, address, floor, room number, etc.
EquipmentType = workstation, server, com device, telephone equipment, CCTV recorders and cameras, and RACK
Equipment = specific id of a piece of equipment and its EquipmentType and Location
EquipmentPort = number of "hole" where a cable attaches (i.e. a patch panel has lots of ports, a coms punch block has 25+ rows and 4 columns)
CableType = type of cable with cable specification and type of terminals (so, if you use cat5x for both telephones, CCTV and 1000BASE-T)
Cable = number of cable, CableType, length, etc.
CablePortType = type of port
CablePort = EquipmentPort(s) the Cable goes to (remember some cables, like in security cameras, go to more than two ports)
Technician = contact information of people that can touch cables.
CableTran = the date a Cable is installed, modified or moved, Technician did the wiring, note of what and why was changed, etc.
Have fun!
Note: I just saw the design by accesstos, and that is good, just think a bit. Is a rack a piece of Equipment that needs its own table? Why do only racks have location data? What about Equipment(s) that connects without a rack? Do you really need two DevPorts tables (and isn't that limiting)? I'm not sure one needs cable type and kind. Is there an asset management system that already has some of this data, and will you want to interface with it? What's the difference between name and description when talking about inanimate objects? Why include part of a table name in a field name? Why make table names plural? Might you want a report that starts with a piece of equipment that isn't working and that shows every step of Cable or Equipment that sits between it and it's end host/client? But he's thought out a pretty good schema for-->iteration 2.
Instad of lots of definition tables like tlkpPortKinds and tlkpCableKinds, check out my thread here:
One table to create a hierarchy instead of many tables. How to create “link” logic? (accessforums.net)
Last edited by twgonder; 06-20-2022 at 04:59 PM.