Reloading Software Recommendations?

[soldernut]

I do quite a bit of reloading, and am tired of keeping track of things on paper.

I'd like to find a good Windows program for reloaders. I don't care about external ballistics features. I do care about recording detailed load data - and the results.

I'm a software engineer, so could write it myself - but I don't believe in reinventing wheels.

Suggestions?

 

[Rick Courtright]

Hi,

Not sure I know what you want: I just set up a spreadsheet to duplicate what I'd been scribbling here and there in notebooks and such.

My brother in law was talking of setting up a database for his info, but don't know if he ever got around to it (he still has the ol' scribbled notebooks w/ him when we go to the range!) You can PM me for a "partially redacted" copy of my Excel s/s if you wish.

A lot of software's available, from free to moderately pricey, but I think you'll find it's usually gonna have some ballistics capability. QuickLoad and AmmoGuide are a couple that folks seem to like. A quick search for "reloading software" will lead you to some of the "other" forum discussions on these, w/ appropriate liinks.

Good luck!

Rick C

 

[soldernut]

Thanks Rick,

I have quite a list of precise "requirements," (roughly what us software geeks call "features"). But it would take a long and probably very boring post to list and explain them all. So I decided to not do that.

Spreadsheets are useful for many things, and I use them a lot. I could start putting data in a spreadsheet but, for my needs, it would wind up an exercise in pounding square pegs in round holes. (I wish I had a dollar for every time I've seen a client using a spreadsheet when a database would have been the proper tool.)

I'll check out the programs you mentioned - as well as others people suggest.

And I'll confess to an ulterior motive: If the best of the suggestions come up lacking, I may have identified a market for my own efforts. :lol:

 

[Cherokee]

Many years ago, I started keeping my records on a Tandy 1000 using a "word" type program. I morfed it into MS Word when that became an established product. I use a template and enter the data. I would guess you are thinking about searches, sorts, etc type functions which I would like to have but do not want to re-enter a thousand plus basic records which have 30 years of notes. If you want to see what I do in Word, let me know via PM.

 

[soldernut]

Many years ago, I started keeping my records on a Tandy 1000 using a "word" type program. I morfed it into MS Word when that became an established product. I use a template and enter the data. I would guess you are thinking about searches, sorts, etc type functions which I would like to have but do not want to re-enter a thousand plus basic records which have 30 years of notes. If you want to see what I do in Word, let me know via PM.

Thanks for your reply.

I've actually been thinking about this for several years, and I imagine you've done some pretty clever things using a word processor and templates. Watch out, you may get that PM.

Meaning no offence at all, I view this as a task for a database application, which is one of my fortes. I'd love to have a dollar for every time I've seen a client using a spreadsheet or word processor when a database was actually the correct tool.

A couple years ago, our company was engaged to help a gold mining concern with their "dispatch" system. The requirements were pretty hairy. Every miner, and every piece of equipment in the underground mine, had to be accounted for and tracked in real time by an above-ground dispatcher. It wasn't just about producton - it could be life-or-death.

This outfit had spent well over a quarter-million bucks to have a high-priced consultancy set up their dispatch system. The consultants delivered over 90 inter-linked Excel spreadsheet files to comprise a "dispatch system." To maintain any kind of history, those files had to be saved at the end of each shift, an according to a strict file-naming convention.

Worse, if the dispatcher inadvertently dragged a cell containing forumlae to the wrong place, it blew up the entire system. When that happened (and it happened at least once a week), the company's IT person had to spend days unscrewing the mess. Most weeks that's all he could accomplish - not time for his other duties keeping their IT infrastructure healthy and stable.

We gave them a properly designed dispatch system based upon a robust database for less than $50,000 - and there was no way for a user to accidentally hose the data.

There's an old Russian proverb that's applicable to my line of work: "When the only tool you have is a hammer, everything looks like a nail."

In my mind, a proper reloading applicaton would track all the details about:

• Calibers (primer to use, max COL, Trim-to-Length, etc.)
  Manufacturers of components.
  Propellants (tied to manufacturers, of course, and burn rate, and with an area for ad-hoc notes)
  Bullets (caliber, weight, type, manufacturer, notes)
  Primers (size, type, manufacturer)
  Data sources (which reloading manual or maybe web site)
  Recipes (caliber, bullet weight, primer type, propellant, charge weight, published MV and pressure, and actual MV results - from chronograph work)
  Batches (recipe used, quantity of rounds, date loaded, chronograph results, group size, notes)

(The above is just a sketch - the tip of the iceberg)

I think it should also print targets and ammo box labels.

I'm not very interested in the external ballistic calculations: That's a wheel already invented.

The question is simply this: Does what I want already exist in a solid, reliable program - or might it be worthwhile to build it?

 

[Rclark]

Well, to me it's why overkill. Float your own boat though... All I care about is 'Does this load shoot well ... in this gun?'. If not try another . A notebook or spreadsheet work fine for this. Heck in a lifetime I'd never fill up one spreadsheet! Labels for my cases come with the case... Or if you run out (never have), there is avery stickers to write on.... Targets are paper plates, cans, bottles, etc.... which are easy to come by. Reloading manuals and such tell me enough about the powders, burn rates, COL, etc..... That's your database! There is a such thing as to 'much' information . There is an American proverb in the software business (my line of work) called the KISS principle . Keep It Simple Stupid.

 

[Yosemite Sam]

Sounds like you've got some special requirements, so as is standard in the s/w world, build it yourself!

But as Rclark's post implies, replicating data that exists in other sources can be a pain. What if you base all your data on (for instance) Speer #13, and when #14 comes out some of that data changes? How will you know?

Funny how many programmers we have around here...

-- Sam

 

[soldernut]

Well, to me it's why overkill. Float your own boat though... All I care about is 'Does this load shoot well ... in this gun?'. If not try another . A notebook or spreadsheet work fine for this. Heck in a lifetime I'd never fill up one spreadsheet! Labels for my cases come with the case... Or if you run out (never have), there is avery stickers to write on.... Targets are paper plates, cans, bottles, etc.... which are easy to come by. Reloading manuals and such tell me enough about the powders, burn rates, COL, etc..... That's your database! There is a such thing as to 'much' information . There is an American proverb in the software business (my line of work) called the KISS principle . Keep It Simple Stupid.

In spite of my love for software and databases, I remain a big believer in paper & pencil. Some of my colleagues at work don't get that but, as I tell them, "Some things are too important to trust to a computer."

They walk away shaking their heads, but I do what I do - get 'er done.

I'm also a big believer in the KISS principle - and one other principle that completely escapes colleague and clients alike: "Just because a thing can be done, doesn't mean it should be done.

All that said, I think the right software could make the experience of reloading - and trackign results - a lot more ordered, a lot more convenient than I've yet managed on paper or spreadsheets.

I guess it all comes down to individual preferenes about the best way to go about a given task.

I haven't decided to undertake the project - I just remain tempted...

 

[soldernut]

Sounds like you've got some special requirements, so as is standard in the s/w world, build it yourself!

But as Rclark's post implies, replicating data that exists in other sources can be a pain. What if you base all your data on (for instance) Speer #13, and when #14 comes out some of that data changes? How will you know?

Funny how many programmers we have around here...

-- Sam

Oh! Believe me, I have no intention of replicating anybody else's data! First of all, pre-populating a database with load data would be tedious, error-prone, and fraught with liabilities. No thanks.

If I built the program, the way I'd begin using it, it would be to record only the existing data that interests me.

That is, the program's database would start out pretty much unpopulated. It would be up to the user to enter the data that interests him. Why reproduce anybody's entire manual when most of us shoot only a handful of calibers?

Among the things I'd like to do is record a "batch" of reloaded ammo based upon some recipe from some trusted source - then track my results with that batch. Weapon used, distance, conditions, group size.

A function to enter a string of chronograph readings and calculate the interestig data points would be easy to write - and highly interesting to me.

Same goes for evaluating a lot of purchased or self-cast bullets. How consistent is their weight? How consistent their outside diameter? Again, functions to record a representative sample could give me average, mean and standard deviation - good benchmarks for bullet consistency.

 

[c.r.]

just a thought............. doesn't Access have a "template" database for cooking recipes? I'm not sure if it still does, haven't looked there in while.

Either way, it seems by simply changing a few column headings here and there, the Recipe template could easily be modified to track the details listed above.

The way i see it, there really is no difference between a dish recipe and a particular load.

I can't see it being that complicated of an Access program. just depends on how "pretty" you'd like to make it.

One could easily Access it to print the load on various sized labels to stick on your loading box.

IMHO, the reason why so many folks use Excel to document their loads is because excel is so similar to a 3-ring binder with tabs inserted. The 3-ring binders work. Excel is relatively easy to use and it allows folks to organize their data just like they're using pencil and paper. As you know, with data bases there are relationships to build and ............. well it can be a bit more complicated, and even though there may be more features available, all the average reloader will do with a database, they can do with excel.

so while some of us may choose to use a database for our record retention, i don't think there is much of a "market" for it among reloaders

 

[Rclark]

And you don't have to use Excel.... Open Office Calc does just fine.....

One thing I've found is one recipe may work fine for one gun, but not for another. Almost like starting over each time.... In a 'perfect' world, we wouldn't have to keep trying new recipes...... Guess what I am saying is all recipes are just starting places when working up loads for a new gun in our stable. May work... may not.... That's why I don't have much use for all the above info as the 'results' change from gun to gun.... It sure would make shooting easier if 'a' load was impossibly accurate in all guns . None of the above discussion would be necessary!

 

[soldernut]

just a thought............. doesn't Access have a "template" database for cooking recipes? I'm not sure if it still does, haven't looked there in while.

Either way, it seems by simply changing a few column headings here and there, the Recipe template could easily be modified to track the details listed above.

[sn] I was skeptical about that, but I went ahead and created an Access project from the "Nutrition" Template - the only one that seems to have recipes. Have you looked at it?

There is nothing in there that could be shoehorned, for example, into storing chronograph readings. Sure, you can create recipes but, just as with reloading, a recipe eventually becomes a dish (some quantity of loaded cartridges). There's nothing in there to record the meals prepared from a recipe; not the date you prepared them, not where you served them, not ambient temporature and wind conditions. Nor can you record the results of cooking them (how they turned out; how well people liked them)

If you look at it carefully, you'll find that it's quite sophomoric in its design, worse in its use.

Typical of Access "applications," it offers the end user very little of the elements necessary for CUA compliance, simple things, like a main menu.

The way i see it, there really is no difference between a dish recipe and a particular load.

[sn] You can't see the difference? In the recipe "application," you can put anything you want into your recipe. In a load, there are just a few components, with very specific purposes, that you can use. You can use only one primer. (The recipe "program" would let you use five primers, each a different kind.) You can use only one powder type in a reloading "recipe." The Access program doesn't even have the rudiments of specifying ingredient types.

In fact, if you look closely, their ingredients table is a simplistic joke. An ingredient is simply a name, and a pre-specified quantity, tied together in one record. Want to use 3/4 Cup of apple juice? Sorry, you get to choose one cup - or nothing at all.

I can't see it being that complicated of an Access program. just depends on how "pretty" you'd like to make it.

[sn] "Pretty" has nothing to do with an application's basic complexity, though "eye candy" can certainly make things unnecessarily harder. Requirements drive basic comlexity.

For this sort of program, one of the first things I'd do is design a suitable database - never mind how "hard" a proper database design might make things with a particular tool, like Access.

Now, Access happens to have a pretty slick database under the covers. It's called the Micrsoft Jet Database Engine. Unfortunately, if you want to share an Access program with others, either they must already have Access, buy it, or you must create an installer program that deploys the redistributable parts of Access, including the Jet engine, and, in doing so, you have to comply with a nearly inscrutable Microsoft licensing document.

One could easily Access it to print the load on various sized labels to stick on your loading box.

[sn]Yes, Access has pretty good reporting capabilities. But I have reporting tools I like better. I'm very fond of my Dymo (now Avery) LabelWriter. It's a very neat little printer for labels that come on rolls. There's a great selection of label sizes. Sizes that would fit nicely on the top of ammo boxes, the sides of ammo boxes, etc. With the tools I like, it's easy to create "reports" for those different lables. With Access? Probably not so easy.

IMHO, the reason why so many folks use Excel to document their loads is because excel is so similar to a 3-ring binder with tabs inserted. The 3-ring binders work. Excel is relatively easy to use and it allows folks to organize their data just like they're using pencil and paper. As you know, with data bases there are relationships to build and ............. well it can be a bit more complicated, and even though there may be more features available, all the average reloader will do with a database, they can do with excel.

[sn]I have no criticisms of those that prefer to use Excel. It's there, and it is pretty easy to use - depending on what you want. I use it, a lot, myself. But it's not the tool I'd choose to record my reloading data; well, except as a stop-gap measure.

A spreadsheet is great for one-off tasks. But when you begin repeating work, like resizing column widths, sheet after sheet, something's wrong.

Some of the things that ought to be done in a good reloading solution are just downright tedious to accomplish in a spreadsheet: Things like providing a drop-down from which you can select only a primer suitable for the caliber you're loading, or checking that your charge weight falls between the starting and "never exceed" values for the caliber, propellant, and bullet type/weight you're using.

You're right. Doing it with a database does entail extra work; lookup tables, relationships to be enforced, etc.

To me, data validation is a hallmark of a truly useful and robust solution. It can be done in Excell, but how many reloaders that use a spreadsheet actually take the trouble to set that up?

so while some of us may choose to use a database for our record retention, i don't think there is much of a "market" for it among reloaders

[sn] I often create programs with little thought as to "market." Sure, it's nice if there is a market, but I'm a market of one. :lol: Works for me.

 

[soldernut]

And you don't have to use Excel.... Open Office Calc does just fine.....

[sn] You bet. I'm a big fan of Open Office. I love what they did "to" Microsoft: Instead of using a proprietary, binary data format for their documents (spreadsheets, papers, etc.), they designed an open and human-readable document object model based upon XML.

The Europen Union adopted that as a standard, which forced Microsoft, with the latest versions of Office, to follow suit.

Those of us programmers that have to muck around in documents will reap a big boon from this.

One thing I've found is one recipe may work fine for one gun, but not for another. Almost like starting over each time.... In a 'perfect' world, we wouldn't have to keep trying new recipes...... Guess what I am saying is all recipes are just starting places when working up loads for a new gun in our stable. May work... may not.... That's why I don't have much use for all the above info as the 'results' change from gun to gun....

[sn] Absolutely true and one reason I'd design the program with multiple "levels." One would be the basic, published recipe; the starting point. It's invaluable because it gives us all the parameters within which we had better work.

The next level would be "Batches." A batch would be some quantity of ammo reloaded within the parameters of a particular recipe. A batch would record exactly what we did with that recipe: precise primer used, precise propellant, charge weight, exact bullet used, degree of crimp, date reloaded, quantity reloaded.

Another level would be Results. Results wouldn't be tied to a recipe, they'd be tied to a Batch. Results would let us record the firearm used, the date, ambient temperature, wind conditions, chronograph readings, group size(s) at what range(s); even scans of our shot-up targets and images of our fired cases (if we had bulged primers, for instance).

Results would be where we'd find our ideal loads for a particular firearm.

It sure would make shooting easier if 'a' load was impossibly accurate in all guns . None of the above discussion would be necessary!

In a perfect world, that's how it would be. We have two .357 Mag revolvers: My wife's Ruger SP-101, and my Ruger KGP-141. No way does the same load work equally well in both guns. The only load that comes even close is the classic .38 Special target load: 148 gr. wadcutter over 2.8 grains of Bullseye.

As soon as I move into "magnum" territory, what works great in one works not quite so great in the other.

The difference in optimal loads is often subtle - sometimes just a small change to charge weight. Sometimes the difference is more dramatic, like when one propellant works better (all other factors being equal) in one gun than in the other.

Fortunately, it's not a perfect world, so we have an interesting hobby, challenge, whatever you want to call it.

That's why I'm interested in a solution that can track results. It seems the single, best way to go at this scientifically.

 

[soldernut]

RCBS.LOAD allows the user to track custom loads--every variable. Check the reviews in my previous post.

CDFingers

Thanks for the reminder. I will check. No way do I want to reinvent a wheel. :lol:

 

[soldernut]

RCBS.LOAD allows the user to track custom loads--every variable. Check the reviews in my previous post.

CDFingers

Thanks again for reminding me. I did check.

I love Midway reviews, but you do have do scroll down past all the 5-star ratings to discover what people don't like about a product.

Almost everybody that posted a negative comment mentioned one thing that's important to me; the user interface. They say a lot of things about it, but the bottom line seems to be that the RCBS UI sucks.

I see a lot of that. I've been guilty of designing shabby user interfaces myself - until I learned better.

About ten years ago, I was invited to beta test a new program by one of my Internet developer "buddies." When I saw his user interface, I was blown away - and not because of "eye candy." Sure, he'd made it attractive. But he'd also made it as close to obvious-to-use as such a program could be.

So I inundated him with emails - picking his brain - and learned a ton.

That experience made me passionate about good UIs, and I have little patience for poor ones.

Mind you, I'm a programmer. We have to put up with some pretty crappy user interfaces in some of the utility tools we have to use. I can live with those, but I take them as lessons in how not to do various things.

Once a programmer undersands that it doesn't really take much extra work to make s superb UI over a clunky one, he has little excuse for doing less.

The RCBS software may very full-featured. It certainly sounds like it is.

However, from my point of view, if they're promulgating a lousy UI, they just created an opportunity for me. Heh, heh.

Good UIs are one of my strong suits.

 

[soldernut]

I agree about the UI. For the first several times of use it took me a while to set up the databases for each load. I think the trouble with the UI lies in selecting the loading manuals that the software will use to do its decisions. The list of manuals is just a list, so if you don't know what's in that particular manual, it's confusing. Same idea with bullet choices: if you don't know that particular bullet, you have to look it up outside the software.

[sn]That's a common problem in software that has a limited audience. With highly popular and mature programs, such as MS word or Corel WordPerfect, the authors (despite appearances sometimes) really do pay attention to what their users say about ease of use, intutitveness, etc.

They go so far as to set up study groups, ten to thirty ordinary users, who are asked to use the program while being observed. Sometimes those users will be using the same program, but with different UI features. The authors pay close attention to what is and what is not working well for users.

With software that has a smaller perceived market, the resources devoted to development are typically a lot less. Often it's a one-man effort, and there are few developers that are good at every aspect of building software: selecting the best database for the job; choosing the best development tools and third-party libraries; database design, proper implementation of data validation; program navigation/flow; user interface design; testing; authoring good on-line help; even installer program authoring and testing. Then there are process (its own discipline in computer science), and ALM (application life-cycle management),

What typically happens is that a product is eventually "finished" and, if it's "good enough," it gets branded and deployed.

What happens later on is almost entirely dependent upon ROI (return on investment). If it sells well, there's money for ongoing enhancement. If it doesn't, and/or the market is perceived as saturated, it progably gets little attention.


Now that I know, it's quick for me, but I adapted and it took some effort. To tell the truth, I'd not remembered those first few weeks, as I've used it now for several years--I'd assumed that the trouble stemmed from me being an old fart from the paper and pencil era (nearly everything "computer" takes me time to learn).

[sn]Don't sell yourself short. You sound a lot like me. Much as I love computing technology, I'm still a paper & pencil guy for many tasks. Then there's the business of software standards. There really are such things, and Microsoft put a lot of effort into publishing theirs, the "CUA."

The idea with CUA is that, once a windows customer learns to use one program, a high percentage of the skills needed to use a different program will already be in place. This only works, of course, if all parties understand and follow the standards. Unfortunately, they don't.

To make matters worse, several companies sell "desktop databases" (Access, Paradox, etc.) that are hyped as easy tools for developing applications. They might be that, but they don't lend themselves to easily creating CUA-compliant programs. Instead of the standard main menu at the top (file, edit, view, help), their users are urged to create "dashboards" to support navigation. And it goes downhill from there.


I don't know if there's a more "modern" version. When you find a good one, I'm sure there are others besides me who would love to find out about it. Best of luck on your quest.

CDFingers

[wp] I'd love to hear from users that have the latest version of the RCBS program - or another - that feel that the program is well designed with an intuitive user interface - and sensible ways to enter crucial data.

As best I can tell, the RCBS program still sports its outmoded user interface, and I'm not about to shell out the ~$100 asking price to find out.

I'm definitely leaning toward writing my own. Two of the neat things about that:

1: I get the program I want; one that meets all of my requirements, and

2: It could be sold or licensed to any one of a number of companies in the reloading business that either have no software to offer - or even if they do, would be delighted to replace it with something better.

I've already begun the analysis and one thing is clear: it won't be a trivial undertaking.

 

[soldernut]

I'd be willing to buy it if you're willing to sell it--but I don't know if I need it, see: I don't know what I don't know about my version of the RCBS software. While it works for me, I don't know what else it could do or what else I need it to do. so, I'd be interested in learning about your version.

CDFingers

[sn] I'd be interested in learning more about my version, too! :lol:

I'm only half-kidding about that. I have a very good idea about what I want, but that's a far cry from hammering out all requirements and coming up with a basic design.

If there's ever such a thing as a first public version, I can easily tell you what it won't have:

1: It won't have a ton of load data. In fact, it'll have none. There are four reasons for this:

* I have to be assiduous about not stepping on others' copyrighted data.

* Liability. If I publish load data, if it contains an error, and if somebody gets hurt because of that, I'd be in a heap of trouble.

* Most reloaders are probably like me; I care only about a few calibers at most. I buy reloading manuals, and ignore 90% of the load data in them. I only care about 9mm, 38 Special, .357 Mag, 40 S&W, 30-30, .308 Win and 45/70.

* I will make it easy for the end user to transcribe load data from any source he pleases. So imagine a personalized "Load Book" that contains load data from as many sources as you choose, but only for the calibers you care about reloading.

2: It won't have external ballistics functions; at least not in an early release. That's not because I don't know how to do it; but for a pragmatic reason:

I've never found them all that useful. Interesting? You bet. In practice, though, I learn everything I want to know about external ballistics at the range when I sight in my guns.

I probably will include some functions for compuing kinetic energy, momentum and, maybe, a couple other interesting metrics at muzzle velocity.

My thinking about this is influenced by a bunch of published data that I have - and have seen. I have several reloading manuals and just one of those "One Caliber, One Book" loadbooks. Both are valuable, and I want the best of both worlds.

The "how to" introductory chapters in the reloading manuals are invaluable, but I dont' plan to reproduce them.

The Load Books are pretty neat and what I wish they were is sort of what I'm after. Where the load books basically photocopy all the load data they can find (on one caliber) from many sources, and divide that data by source, I'd like an "electronic load book" in which all the load data could be "intermingled" in an orderly way.

So imagine I've pulled up my load data for, say, 9mm. I'd list the load data by bullet weight, bullet type, then in descending order by, say, maximum velocity at the "never exceed" charge. The information from various data sources would all be in that one "list."

For now, though, it's something of a pipe dream. I spend my entire work day doing programming and related tasks. I'm not sure I'm geek enough to keep at it spare time, too.

 

[Rick Courtright]

So imagine I've pulled up my load data for, say, 9mm. I'd list the load data by bullet weight, bullet type, then in descending order by, say, maximum velocity at the "never exceed" charge. The information from various data sources would all be in that one "list."

For now, though, it's something of a pipe dream. I spend my entire work day doing programming and related tasks. I'm not sure I'm geek enough to keep at it spare time, too.

Hi,

Some interesting ideas... just one suggestion, KISS!

I understand your comment about using a database in place of a spreadsheet, in appropriate places. So far, though, I don't see anything in your list of requirements or "desires" that I can't do w/ my spreadsheets already.

That's not to say the spreadsheets are the "better" solution, just to say the "problem" you're working to solve isn't all that complex!

Admittedly, the database solution probably would be a bit more "bulletproof" as one doesn't have to worry about accidentally "missing" when sorting data and wiping out a spreadsheet.

And, if you choose to write it up in a database program, PLEASE use something that works faster than a single stage press that needs oil! Dunno why, but a majority of folks I know have this affinity for Access. Perhaps that's cuz so many computers have it? I'm surprised that program isn't illegal...

So keep it light, fast and easy to use and you might have a winner!

The UI thing you mentioned is probably the key to success or failure: I know for myself, I have a very low tolerance level for "weird input drills" and don't like to have to take 20 minutes to figure out how to get something into the computer I could have written down on a cocktail napkin and been using in 10! As CD notes, that's a handful of shells that COULD have been loaded.

Everybody's got their own ideas on what's "easy to use" but if you have a copy of Lee's "Modern Reloading," I personally like the way it's set up, and kinda think it MIGHT be on the path you're exploring. 'Tis worth a look if you haven't already...

Good luck!

Rick C

 

[soldernut]

Hi,

Some interesting ideas... just one suggestion, KISS!

[sn] Trust me: I'm a big believer in KISS. But I'm also a fan of the quote often attributed to Mr. Kalishnikov, inventor of the AK-47: "A thing should made as simple as it can - but no simpler."

>I understand your comment about using a database in place of a spreadsheet, in appropriate places. So far, though, I don't see anything in your list of requirements or "desires" that I can't do w/ my spreadsheets already.

[sn] Then I would submit that your are a very advanced spreadsheet driver! In an earlier post I mentioned the importance of data validation. Suppose I'm working up a load for 38 Special and try to specify the SKU for a CCI large pistol primer. The program shoud not permit that because 38 special uses only small pistol primers.

What I think the program should do, instead, is present me a drop-down list of only primers suitable for 38 special.

Can you do that in a spreadsheet? I'm sure you can, but it's not trivial. Can I do it using a database and a modern RAD development tool, like Delphi? You bet - and it's almost trivial to do it.

In a good reloaders' program there are almost too many places that call for data validation to list, but I think that one example gives you an idea.

>That's not to say the spreadsheets are the "better" solution, just to say the "problem" you're working to solve isn't all that complex!

[sn] Complexity is in the requirements. If you can be satisfied with a neatly formatted page of reload recipes, one in which you are responsible for making all the proper entries (and keeping them consistent), a spreadsheet is fine.

But when you want to record not only "recipes," but "batches" loaded with a particular recipe, and then record a number of different result metrics for each batch, things do start to get interesting.

Oh, and when you've loaded up that batch, can your spreadsheet easily print one of several different kinds of targets with the load data already printed in one corner of the target?


>Admittedly, the database solution probably would be a bit more "bulletproof" as one doesn't have to worry about accidentally "missing" when sorting data and wiping out a spreadsheet.

[sn] Yes. That sort of thing happens to spreadsheets all the time. It is easier to prevent those kinds of blunders in a database application.

>And, if you choose to write it up in a database program, PLEASE use something that works faster than a single stage press that needs oil! Dunno why, but a majority of folks I know have this affinity for Access. Perhaps that's cuz so many computers have it? I'm surprised that program isn't illegal...

[sn] Ah, Access! Access is ubiquitous because of some unfortunate hype. And it's not alone in that offence. Paradox and dBASE were also touted as "relational" databases back in the day that "relational" was an important buzzword. What the vendors never told the customer, though, is that it takes a solid understanding of relational database theory to get one damn bit of use out of the products relational support!

Access is really three products in one. Under the covers, there's the Microsoft Jet database "engine," which is actually a pretty nice, good performing database. I've created several solid applications using the Jet engine (but would never think of using Access to develop the application.)

Then there's the "entry level" ways in which Access can be used to create some useful, semi-applications without having to know anything about programming. I don't have anything against that as long as the limitations don't get in the way of what needs to be done (and done properly)

The third Access "product" shows up when a user dips his toes into the programming end. Doing that involves writing code in VBA (Visual Basis for Applications). It's a mess. Every bit of code you write gets tucked away under window after window until it's nigh impossible to tell what's going on. No thanks!


>So keep it light, fast and easy to use and you might have a winner!

[sn] I'm a huge fan of light, fast and easy to use. The toolset I'd use to build such a program is suited to exactly those attributes. For development, I love Delphi. There's a saying in the industry: "Visual Basic makes the easy stuff easy; Delphi makes the hard stuff easy." My database of choice would be one of two most people never heard of; DBISAM or ElevateDB. They're Delphi-nerd databases; light, fast and reliable as an old shoe.

>The UI thing you mentioned is probably the key to success or failure: I know for myself, I have a very low tolerance level for "weird input drills" and don't like to have to take 20 minutes to figure out how to get something into the computer I could have written down on a cocktail napkin and been using in 10! As CD notes, that's a handful of shells that COULD have been loaded.

[sn] So true. Techie that I am, I remain a huge user of pencil & paper. I don't use a computer program for everything I do in life; don't even own one of those "smart" cell phones (iPhone, Android, Blackberry). And there are implementations of technology I detest - like the "programming" features of my Microwave or entertainment system.

If I write a program, I get downright passionate about the UI. I don't understand why so few programmers get that. They spend every hour of their working lives using many programs. Some have okay UIs, some have great UIs and some have UIs that stink. You'd think they'd learn - and care - about the differences. Alas, few do.

Everybody's got their own ideas on what's "easy to use" but if you have a copy of Lee's "Modern Reloading," I personally like the way it's set up, and kinda think it MIGHT be on the path you're exploring. 'Tis worth a look if you haven't already...

[sn] Are referring to the hardcopy Lee manual, or the "Shooter Program" they market for $20?

I have the hardcopy manual - and love it. You can bet I'll be stealing a few ideas from it. There are things I like about some of my other manuals, too: Hornady, Lyman, Speer.

If their software, I haven't seen it but I'm already a little put off by the caveat on Lee's own web site: "Note: Lee Shooter Program has limited compatibility with Windows versions after Windows XP"

Yes, when MS released Vista, they changed several of the "rules" about how proper programs should behave and where they should store their data. It was a pain coming up to speed on that stuff. But, somehow, I just can't see that as an excuse for continuing to market a program that's fallen behind the times.

Good luck!

Rick C

Thanks! I'll need it!