Shop tool and machine inventory application

[tq60]

With Microsoft doing the 365 thing it is a pain.

Basic spreadsheet without formulas I a simple way to START.

Just create a title or header row across the top, here is the labels for each of the fields or data items you wish to use.

Always have item number in the first column.

Formatting the cells can be an issue, dates get converted to numbers sometimes.

Poor man's backup, safe the file as "shop inventory" DATE, where you add the date to the name, this creates a new copy so your old one stays intact.

Add categories, makes finding things easier.

It is really easy to do.

You can turn on the filter function to create drop down selection boxes for each column.

Ours now has 1600 lines of stuff.

Working on database to import, another project.

Sent from my SM-G781V using Tapatalk

 

[PNW_Guy]

Here's an image of my spread sheet for the person who said Excel was difficult. This is Google Sheets, but they are all quite similar. The trickyiest thing I did was freeze the top two rows - everything else is typing, and there's only one formula (sum).

It's been pointed out that a spreadsheet isn't the best option, and I agree. However, it gets things written down and potentially backed up so you have info for the insurance company.

 

[SouthernChap]

Sorry you take it that way.

Feel free to use whatever program you like. But as an IT professional my job was to protect the information my company depends on.

Excel is a great program for analysis but it’s not designed to be a database. If it were Microsoft wouldn’t need to offer database software and tools to connect Excel to SQL.

The file size limit has probably grown since 1999 when I was called to try and recover that spreadsheet. Microsoft was consulted at the time but there was nothing to be done. Data lost, and they didn’t have a usable backup. Made a big impression on me then.

John

Eh, whilst tools are often for what we use them for, I have to agree.

These days, with software development being more accessible and cloud hosting of Web applications and their persistence layers being relatively inexpensive, even small companies will often have reasonably appropriate (if not well crafted) software for their needs.

That said, I know of a small company that still uses a terribly written Access application, writen by someone who had zero formal training in good software development practice and very little talent to compensate for their lack of training (not that talent can compensate for knowing next to nothing about software craftsmanship or good DB design), for their back office operations and what appears to be a website knocked up poorly using some CMS software. Needless to say, the two applications have no capability to communicate.

I am probably going to provide some 'consultation' on the understanding that the owner doesn't pay me and won't sue if they take my good advice and misuse it!

 

[matthewsx]

Here's an image of my spread sheet for the person who said Excel was difficult. This is Google Sheets, but they are all quite similar. The trickyiest thing I did was freeze the top two rows - everything else is typing, and there's only one formula (sum).

It's been pointed out that a spreadsheet isn't the best option, and I agree. However, it gets things written down and potentially backed up so you have info for the insurance company.

View attachment 480418

Spreadsheets are fine for an application like this where it's unlikely to get very large and there's little consequence to having issues if they arise. In fact, if you put your data into one then it's fairly easy to import into a database in the future as long as you structure things like the example above. The one thing that's missing here though is a key data field, like item number which would come in very handy if you ever have two of the same item and want to differentiate between them. Also needed if you want an asset tag system to label tools.

A simple database like the one @Dan Krager has would be good in that it allows the user to simply input their data without worrying about the structure. When you start entering data it's easy to have fields that you don't enter right away but may need later, it's more of a challenge to introduce them later when you've already committed to a structure.

Much like machining, it pays to think several steps ahead before committing.

John

 

[GeneT45]

Sorry you take it that way.

Feel free to use whatever program you like. But as an IT professional my job was to protect the information my company depends on.

Excel is a great program for analysis but it’s not designed to be a database. If it were Microsoft wouldn’t need to offer database software and tools to connect Excel to SQL.

The file size limit has probably grown since 1999 when I was called to try and recover that spreadsheet. Microsoft was consulted at the time but there was nothing to be done. Data lost, and they didn’t have a usable backup. Made a big impression on me then.

John

We ran into this at a place I worked circa 2000. It wasn't so much a file size limit, IIRC, it was a limit on how many cells you could have in a *row* (i.e. how many columns you could have). At least for practical purposes, the number of rows was (or seemed) arbitrarily long. And we weren't using a spreadsheet as a database, but we were trying to analyze large data sets. We switched to a unix spreadsheet called "Wingz" that worked at that time.

I like LibreOffice for my work at home, and use LibreOffice Calc (their spreadsheet) for a lot of things, including my electronics inventory, which is perhaps better suited to a database, but it's such a simple thing that a 'real' database isn't really necessary. It's very easy to utilize this basic functionality (which scarcely scratches the surface of the spreadsheet capabilities) - you just have to dive in and do it. What little trouble you might have with formatting, etc can be quickly answered with a web search. The hard part is actually doing the inventory and entering the data...

GsT

 

[PNW_Guy]

Spreadsheets are fine for an application like this where it's unlikely to get very large and there's little consequence to having issues if they arise. In fact, if you put your data into one then it's fairly easy to import into a database in the future as long as you structure things like the example above. The one thing that's missing here though is a key data field, like item number which would come in very handy if you ever have two of the same item and want to differentiate between them. Also needed if you want an asset tag system to label tools.

A simple database like the one @Dan Krager has would be good in that it allows the user to simply input their data without worrying about the structure. When you start entering data it's easy to have fields that you don't enter right away but may need later, it's more of a challenge to introduce them later when you've already committed to a structure.

Much like machining, it pays to think several steps ahead before committing.

John

All good points. I used a Google Sheets because of the almost zero chance of the "backup" failing. Also, I'm not a DB programmer.