401 and HQ Database size

Does doing frequent 401 worksheets significantly increase database size? I suspect not because they are just adding incremental information, but I have updates done every 10 minutes at three stores and recently hit the 2GB MSDE limit. Just wanted to make sure this is not a contributor.

Reply to
Jason
Loading thread data ...

I presume this is at HQ. HQ should not be MDSE but Full SQL even for small installation as HQ acts like a data warehouse of all your stores data. Suggest you upgrade HQ installation to full SQL

Reply to
Afshin Alikhani

That doesn't exactly answer my question. And if that is truly the case, why did Microsoft (via my reseller) rip me off by selling me a product that everybody knows will not work after a very short period of time? I agree that full SQL should be used with HQ (knowing what I know now), but if that is the minimum or recommended configuration, it sure would have been nice to know that before I shelled out thousands of dollars for a solution that was destined to fail me without costly upgrades.

Reply to
Jason

Reply to
convoluted

Any idea how to turn off or delete one of the two printer's journals - I don't need two journal receipts per transaction for sure, but I need at least one. Any idea how to calculate the amount of space journals are taking up in your database? These answers would help me out tremendously.

(sorry for the duplicate post - I asked this in another thread)

Reply to
Jason

I ran into this issue with a client last week where he needed to be able to print either a 40 col receipt for a standard retail sale or a full page invoice for a wholesale sale; I couldn't come up with a solution except to set up both printers and have the system prompt which receipt printer to use on the sale; unfortunately, he wanted the capability to go back and reprint a receipt, so I had to set both receipt printers to journal receipts.

I usually copy onto notepads useful postings on this newsgroup. Here's one I copied some time back that you could probably use to delete old journals; unfortunately, I don't know how to view a "table size" in the database using standard SQL queries; hope this helps

Anyone know what data the Journal table stores. I gather its either all the transaction data or a "picture of the receipt" The journal table is taking up 1.8GB of the total 2.6GB database. If the journal table is just a picture of the receipt, is there anyway I can just keep them if they are less than 30 days old, as I've never looked in the journal for something more than a few days old.

Answer this is true, the Journal table only keeps an electronic copy of the receipt, z,x,zz reports and it always takes a huge amount of space. simply create a job (if u have full sql), add one step: -

"DELETE Journal where time < getdate()-30"

let this job run > Any idea how to turn off or delete one of the two printer's journals - I

Reply to
convoluted

Jason,

To answer your original question, yes frequent 401s will significantly increase your HQ database size after a long enough period. Without sacrificing journal information first try deleting from the 'worksheet' event log . In HQManager, View>EventLog. There is an option to delete logs by date range and store. You can periodically go in there and purge outdated information regarding the worksheet proccessing as long as they have been processing successfully. It is then your option to shrink the database or allow the table to fill the pages back in until you purge again.

Regards, Jeff Taraby eVisi> Does doing frequent 401 worksheets significantly increase database size? I

Reply to
Jeff T

You could upgrade to SQL 2005 Express for free and double your database size limit to 4GB. The full version would be better, but if your budget is tight this will buy you some time.

Deleting old worksheets can help, too.

Tom

Reply to
Terrible Tom

Yes, and when I bought it, they said it would work with Small Business Server 2005......so my upgrade strategy would be to get SBS2005 when I needed to go to a full-blown "real" server and SQL.

Now, SBS is not supported? That sucks.

Mickie

Jas> That doesn't exactly answer my question. And if that is truly the case, why

Reply to
Mickie

I will try deleting the logs. I have little use for them - I routinely verify all worksheets process successfully.

What is the procedure to shrink the HQ database after deleting the logs?

Reply to
Jason

Thanks for the recommendations. Deleting old worksheets sounds like a great idea. I never even really thought of this as an option because I do like the history of who made changes. However, I have absolutely no need for 401 worksheets that processed successfully... The PO Planners all get sent down to the stores, so I can get rid of them, too.

I have about 40,000 Data Uploads (401's). Any suggestion on how to delete them quickly?

Then what do I do to shrink the database thereafter?

Reply to
Jason

Yes, and when I bought it, they said it would work with Small Business Server 2005......so my upgrade strategy would be to get SBS2005 when I needed to go to a full-blown "real" server and SQL.

Now, SBS is not supported? That sucks.

Mickie

Reply to
CptSoft

Could you run a delete/from/where query? I'd post a suggestion but I see there'several worksheet tables you may need to hit. worksheet worksheet_purchaseorder worksheethistory worksheetstore

and maybe others? I'm still pretty green when it comes to the HQ tables; maybe a more experienced HQ user will post the correct SQL -

Is there a KB that lists table def> Thanks for the recommendations. Deleting old worksheets sounds like a great

Reply to
convoluted

Could you run a delete/from/where query? I'd post a suggestion but I see there'several worksheet tables you may need to hit. worksheet worksheet_purchaseorder worksheethistory worksheetstore

and maybe others? I'm still pretty green when it comes to the HQ tables; maybe a more experienced HQ user will post the correct SQL -

Is there a KB that lists table def > > Deleting old worksheets can help, too. > >

Reply to
CptSoft

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.