packing?
> MmTICKER deltes expired baskets and deletes both store and domain data
Err.., I should start reading what I write before sending :)
I wanted to write:
MmTICKER deletes expired baskets, and packs both store and domain data
Ivo Truxa
| http://miva.truxoft.com
| Advanced Miva Merchant modules
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ivo Truxa
Sent: Tuesday, May 10, 2005 10:02 PM
To: 'Miva Merchant Coders'
Subject: RE: [mrc] packing?
In Merchant Admin, there are two functions - Store and Domain packing.
Packing store data indeed does not pack the Modules database and couple of
other shared data files. However, most of those change only little over the
time, so their packing is not as needed as packing the store data.
If the customer likes to pack regularly (what makes sense), he may also
consider using MmTICKER for automated scheduled and secure packing deep in
the night when there is no risk of conflicts with shopping customers.
MmTICKER deltes expired baskets and deletes both store and domain data.
Ivo Truxa
| http://miva.truxoft.com
| Advanced Miva Merchant modules
-----Original Message-----
From: Behalf Of Kent
Hey folks --
Recently I found out that one of my clients like to pack his store twice
every time: he uses the standard admin functions, and also the
OpenMaintenance packing functions. I asked why, and he replied:
>It is redundant but I have found that after packing using the built in
>Miva functions, then opening the OpenMaintenance window, that some of the
>filesizes listed are still larger than the Last Filesize, giving me the
>impression that some of these aren't packing well with the built in
>functions. Once I check them off and pack using the OpenMaintenance
>utility, those filesizes are the identical. Seems I read about this
>somewhere and that's why I started doing it this was last fall sometime.
>Also, the built in Miva packing functions don't seem to do anything for
>the Store Module Tables at all. Don't know why but they don't need packed
>very often it seems, so once a week is fine.
This all seems a little odd to me ... anyone care to comment?
Thanks --
Kent Multer | /| P.O.Box 701895, Dallas TX 75370
Magic Metal Productions | / | (214) 570 8264 voice/fax
| | [email protected]
* Web developer/designer http://TheMagicM.com
* E-commerce and Miva
* Author, The Official Miva Web Scripting Book -- available on-line:
<A HREF ="http://www.amazon.com/exec/obidos/ISBN=0966103211/magicmetalproducA">http://www.amazon.com/exec/obidos/ISBN=0966103211/magicmetalproducA</A>
-
Guest replied -
Guest repliedpacking?
In Merchant Admin, there are two functions - Store and Domain packing.
Packing store data indeed does not pack the Modules database and couple of
other shared data files. However, most of those change only little over the
time, so their packing is not as needed as packing the store data.
If the customer likes to pack regularly (what makes sense), he may also
consider using MmTICKER for automated scheduled and secure packing deep in
the night when there is no risk of conflicts with shopping customers.
MmTICKER deltes expired baskets and deletes both store and domain data.
Ivo Truxa
| http://miva.truxoft.com
| Advanced Miva Merchant modules
-----Original Message-----
From: Behalf Of Kent
Hey folks --
Recently I found out that one of my clients like to pack his store twice
every time: he uses the standard admin functions, and also the
OpenMaintenance packing functions. I asked why, and he replied:
>It is redundant but I have found that after packing using the built in
>Miva functions, then opening the OpenMaintenance window, that some of the
>filesizes listed are still larger than the Last Filesize, giving me the
>impression that some of these aren't packing well with the built in
>functions. Once I check them off and pack using the OpenMaintenance
>utility, those filesizes are the identical. Seems I read about this
>somewhere and that's why I started doing it this was last fall sometime.
>Also, the built in Miva packing functions don't seem to do anything for
>the Store Module Tables at all. Don't know why but they don't need packed
>very often it seems, so once a week is fine.
This all seems a little odd to me ... anyone care to comment?
Thanks --
Kent Multer | /| P.O.Box 701895, Dallas TX 75370
Magic Metal Productions | / | (214) 570 8264 voice/fax
| | [email protected]
* Web developer/designer http://TheMagicM.com
* E-commerce and Miva
* Author, The Official Miva Web Scripting Book -- available on-line:
<A HREF ="http://www.amazon.com/exec/obidos/ISBN=0966103211/magicmetalproducA">http://www.amazon.com/exec/obidos/ISBN=0966103211/magicmetalproducA</A>
Leave a comment:
-
packing?
Hey folks --
Recently I found out that one of my clients like to pack his store twice
every time: he uses the standard admin functions, and also the
OpenMaintenance packing functions. I asked why, and he replied:
>It is redundant but I have found that after packing using the built in
>Miva functions, then opening the OpenMaintenance window, that some of the
>filesizes listed are still larger than the Last Filesize, giving me the
>impression that some of these aren't packing well with the built in
>functions. Once I check them off and pack using the OpenMaintenance
>utility, those filesizes are the identical. Seems I read about this
>somewhere and that's why I started doing it this was last fall sometime.
>Also, the built in Miva packing functions don't seem to do anything for
>the Store Module Tables at all. Don't know why but they don't need packed
>very often it seems, so once a week is fine.
This all seems a little odd to me ... anyone care to comment?
Thanks --
Kent Multer | /| P.O.Box 701895, Dallas TX 75370
Magic Metal Productions | / | (214) 570 8264 voice/fax
| | [email protected]
* Web developer/designer http://TheMagicM.com
* E-commerce and Miva
* Author, The Official Miva Web Scripting Book -- available on-line:
<A HREF ="http://www.amazon.com/exec/obidos/ISBN=0966103211/magicmetalproducA">http://www.amazon.com/exec/obidos/ISBN=0966103211/magicmetalproducA</A>
Leave a comment: