Jim, >Fine, assuming you can scan the bar code - this is not on most PalmOS >devices.
But it is on every one my clients use. That is the whole point of the application. They already have desktop (laptop) applications for sales automation. Those who also want mobile scanner entry get either a less inteligent data collector which does little more than collect the barcodes and quantities (for transfer to the PC application), or now I give them the option of a Palm OS based scanner to provide more feedback. Lots more. >If you can do that then there is even less need to store the 30,000 items Wrong again. It is precisely the ability to store well over 30k items along with all the associated data which makes the Palm OS application more beneficial than a simple data collector. The scanning is just quicker than direct entry, although I support that too (along with searches by SKU, description, vendor, etc; all without sorting on the device). >> I can also give immediate feedback as to stock availability > >No you can't, It is as good as I could provide even with a wireless connection. You don't understand the application here. What we've been arguing all along is that the potential need for large databases depends on the application. Some do, some don't. Here is some more background: My forte is in sales automation for independent sales reps which may represent a single or dozens of product lines. Any given product line may have from dozens up to tens of thousands of products. Each with their own discount structure, sales and promotions, yada, yada. Some product lines have very predictable inventories and you can order anything they carry. They may not provide any access to their corporate systems to determine stock availability; you just place an order. Others have very seasonal and/or limited merchandise and a smart sales rep will want to be able to tell the customer whether a given color and size is (likely) available. If it is not, the best time to inform the customer and give them estimated dates or help them select an alternate product is while you are taking the order. To that end, some corporate systems provide daily (or more frequent) updates on stock availability. A typical scenario: - Nationwide network of sales reps take orders during the day - At the end of the day (or on demand), orders are batched to vendor(s) - Vendor corporate system electronically accepts orders 24 / 7 - At predetermined times (say 3am) it takes snapshots of availability - Those snapshots are picked up by my sales automation system - Prior to hitting the road for the day, the rep updates the Palm database Viola! While taking orders all day, road reps have stock availability as current as the day before whether they sell from barcoded catalogs, sample boxes, mobile showrooms, or permanent showrooms. They also have the most recent estimate on revised ship dates, promotions and price changes. And if the stock is dangerously low, they can call the vendor directly for confirmation and to lock in inventory allocations. Knowledge is power. The more information you can give a sales rep (or their customer) *at the point of contact* the better. Commissioned sales reps don't make money when the product doesn't ship, and the customer isn't happy either. Empower them to know more immediately at the scan of a barcode and you write orders which can nearly always ship 100% complete. Makes everyone happy. >> pricing according to complex discount rules > >Some info is necessary in this case. Quite a bit can be necessary actually, including potentially varying pricing based on the customer. I have clients who store data on tens of thousands of customers on the Palm too. And yes, that *is* subsetted to the customers who may visit a given showroom. >Because it might be stupid. Anyone who thinks the customer is always >riht has never worked in a support department :-) I have worked support and customer service. The top two rules: 1) The customer is always right. 2) When the customer is wrong, see rule #1. Sure there are times a customer needs to be educated. But in this case, *I'm* the one who suggested replacing basic data collectors as a front-end to sales automation with Palm OS based units which can provide volumes of data immediately without the need for wireless networks. (Wireless networks aren't yet practical for nationwide sales groups of road warriors -- even if you could get real-time access to all the corporate order systems.) >> I can handle that many products under Palm OS easily. > >It depends how you handle them. If there is no advantage, and a sync >takes half an hour, why do it? That's how this thread started -- how you handle them does matter, in my experience. And in my field there *is* an advantage, and the syncs don't take a half hour. Typical sites take under a minute each morning and even the large sites take only a few minutes even without network cradles, SD cards, etc. Now if I put one product per record, then yes, it wouldn't get done in a half hour and you'd lose the advantage. That's why I don't do it that way. <g> >My point is not that you **never** need to store all that info, but that >occasions where it is **necessary** are rarer than people think. It all depends on your target market. In my case, it is 100% of the users. My point is not that you **always** need to store all that info, but that occasions where it is **necessary** do exist or you've lost the prime reason for the application. So the thread issue is, when large databases are appropriate, is it better to use one record per data item and sync dirty records, or reduce the record count by increasing the record length? In my experience there is no contest. Use large record lengths. YMMV Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
