I did a trial of Sling TV, but it was when it first came out, and it wasn't very good.

There is a standalone TiVo now that you can use for streaming, I think, but it's expensive.

So, what database platforms are all the cool kids using these days? I just need to build something relational, do a little sql reporting. It's what I would have built in Access last time I was industry adjacent. Would it still be Access? Is there an Open Office thing? Should I just build it on some cloud thing to begin with, since it may later morph into the basis for app development?

I'm still an Access fan, although it's been five years (yikes) since I've done anything in it professionally. I think the cool kids would use sql calls from web pages because, you know, the cloud. Access is still probably the best bet if you want to avoid that. LibreOffice does have a db application as part of its suite, but I haven't used it, so I can't opine.

Ok, cool thanks, DX.

Hah! I just now noticed that in Gmail, when I go to my "Sent" folder, the search field displays "in:sent".

Speaking of Access...

Can any of my database-savvy friends assist with some hints as to how I should proceed with an access database I'm making? At work, they keep giving me excel spreadsheets for different tasks, and none of them are relational. THere's even one (Below Top) that I'm supposed to copy and paste into a sheet for each team member. They are not linked, so to see a team member, I have to find the right sheet. Really. Since I have access to Access, I decided to re-create the Spreadsheet as an actual core database, and hope to pull all the various spreadsheet data into one DB as I work. I've gotten this far (Below Bottom) but can't figure out how to reproduce the month/day fields so they can just be clicked upon to select the proper one. I'm temporarily using a rough "scheduled days" and "Hours" in the attempt, but it's not as useful.

Any suggestions?

[link]

[link]

Daniel, a question. I'm assuming that the grid shown in link 1 specific to one team member, with each team member having their own version of the grid.

In a database, you wouldn't duplicate the grid in a table. You set up a table with entries for each team member for each day, then reconstuct the grid using a query (and/or a report).

It seems to me that you could get by with two tables. The first would have a record for each team member with all the information you show in your form in link 2. In that table you also need to give each team member a unique ID. Then the second table would consist of three fields per record - [Team Member ID],[Date],[Attendance Code]. The table won't be visually useful the way your spreadsheet is, but you can use a query to build the grid for a given team member that draws only the records with the correct team member ID.

You could fancy it up with a third table that contains the symbols and explanations for the attendance codes.

Does any of that make sense?

I do like the idea of adding a table with the [Team Member ID],[Date],[Attendance Code]. Even if I can't make it look the same, at least I can pull up the information to show my own manager

I'm probably not explaining this very well.

I am trying to make it so I can type in a team member, number, or another field for a team member, and have their page come up. I have made the back end with the fields you see in the photo.

The "spreadsheet" they have me using right now indicated in the first picture might as well be a series of images for all the interaction one has. Each square has to be filled by hand with a letter or number and then colored by hand. I'd like to be able to click on a and select one of the choices for the status for that person.

I created a database with all (soon to be more) of the fields you see there (except the date grid), and I then used that DB to design an approximation of what work uses.

In the end, hat I am hoping to do is to be able to keep adding to the main DB, and be able to pull off different outputs specific to the needed forms. This is just the most complicated one they use and I thought I would start with the hard one, and go from there. Oops.

For instance, I have another spreadsheet with each person's coaching plan, each person's upcoming training, and other key data. I have several spreadsheets at work that could be pulled from this one main DB, if I had a coherent table in my access DB.

I hope this makes sense.

Yeah, I think I'm getting most of it. The thing to remember about databases is that the data should be stored in the most efficient manner possible, which is not usually the most convenient manner possible for scanning the data. The idea is not the duplicate data across multiple tables. Enter data once, and then link to other tables as needed.

For your system, it looks like your parent table would have the header data for each team member as a separate record. The fields would include things like [Agent],[Oracle],[Phone], etc. I suggest putting [Schedule Days] and [Hours] into a separate table to provide a little more flexibility. Each record in the main table would also need a unique ID tag, a primary key, that would be used to link to data in other tables. This could be the employee ID, or a sequential number, or some similar unique identifier.

Once that is set up, then add child tables as needed, e.g., the attendance table, coaching plan data, upcoming training schedule, code info and so on. Each of the child tables can then be linked to a record in the parent table using the parent record's primary key, and only through that link. That way, there's no need to duplicate any other information across more than one table. If you do notice duplicate data fields, you can decide where the data should be to work best for you, and remove those fields from the other table. (Note, not everything needs to be linked through the primary key. For example, you can grab data from some tables, like the example I gave about the attendance codes, using simple lookups, much like using the VLOOKUP function in Excel.)

Once you got your tables set up, you get to the tricky part - designing the forms, queries, and reports to let you enter and read the data in ways similar to what you've been doing with the spreadsheets. Queries are the big thing. That's how you link the tables together to get the data you need in the order you want it.

Sorry if you already know some or all of this, or if some it is confused or confusing. It's been five years since I last had to think about most of this stuff, and putting some of the concepts into words gets a little tricky if you haven't used them in a while. Feel free to ask questions here or at my profile addy.

And... just to vent a little...

My main machine died on Saturday. Not sure yet if it's the power supply or the motherboard yet. I haven't had the time to really diagnose it. I do all of my school related stuff on it when I'm at home, but fortunately, I have everything course-related backed up to my trusty keychain thumbdrive. The laptop is less than ideal for working on this stuff, so I pulled the data drive from the main machine and installed it in my gaming machine. Now the gaming machine won't boot. Getting a disk error that tells me to give it the three finger salute and try again... to infinity. Le sigh.

Somehow I must've jangled a cable loose in there somewhere. Now I have two computers to fix. God help me if the laptop fails.