search engine tracker for miva merchant

Import/Export SuperModfor Miva Merchant™

Complete Import and ExportSolution for Miva Merchant

Product Manual

COPERNICUS BUSINESS SYSTEMS www.cbstech.com

COPERNICUS BUSINESS SYSTEMS 2

Table of Contents

Module Description .................................................................................................................... 3 Key Benefits............................................................................................................................ 3 Example Usage 1: Importing Large Product Databases ......................................................... 4 Example Usage 2: Fixing Duplicate Record Issues................................................................ 4 Example Usage 3: Import and Export 3rd Party Module Data ................................................ 4

Theory of Operation.................................................................................................................... 5 General Theory ....................................................................................................................... 5 Module Theory...................................................................................................................... 10

Module Installation and Upgrading .......................................................................................... 14 Domain Installation of Module............................................................................................. 14 Store Installation of Module ................................................................................................. 16 Module Upgrading................................................................................................................ 18

Module Usage ........................................................................................................................... 20 Module Configuration........................................................................................................... 20 CBS – Import/Export SuperMod Tab (Store Utilities Section) ............................................ 21 Export SuperMod: Export Tables to Flat File (Below Store Utilities Section) .................... 24 Import SuperMod: Import Tables to Flat File (Below Store Utilities Section) .................... 26

Legal Information ..................................................................................................................... 29 Copyright Information .......................................................................................................... 29 Corporate End User License Agreement .............................................................................. 31


Module Description The Import/Export SuperMod™ provides advanced data imports and exports for all Miva Merchant databases, including the ability to directly import and export any 3rd party module databases. Any Miva Merchant database can be edited directly in any text editor, spreadsheet or desktop database program such as Microsoft Access and Excel.

Key Benefits • Never purchase another import or export module again! • Export any Miva Merchant database to tab-delimited text file, including 3rd party module

databases • Edit the text file using your favorite desktop application such as Microsoft™ NotePad,

Excel or Access • Import the changes back into your Miva Merchant store • Provides Import/Export capability for modules that do not provide data imports or

exports natively • Fix corrupted databases and store packing issues with a text editor • Time-out safe! Export and import large databases without any worries of the web server

or browser timing out! Features automatic refreshing to cycle through large import files. Miva Merchant storeowners now have a single import/export solution for handling any data transfer operation, regardless of the module provider or Miva Merchant feature. The Import/Export SuperMod can export any Miva Merchant database to flat file. The storeowner can then edit this file and re-import the changes!


Example Usage 1: Importing Large Product Databases Customers who have many products often have difficulty uploading all products through the standard Miva Merchant product import. Timeouts can prevent the import from completing, leaving the store in an unknown state. The Import/Export SuperMod provides timeout protection, and will allow the store-owner to load even the largest of product databases without timeout issues.

Example Usage 2: Fixing Duplicate Record Issues A common problem for some Miva Merchant users, duplicate database records or ids can cause significant operational issues within your Miva Merchant store. Until now, the only way to fix the duplicate records was to edit the Miva Database files by hand, which requires special purpose database software or contracting to a Miva consultant. The Import/Export SuperMod provides the storeowner with an easy way to edit and fix duplicate database records using any text editor, Excel or even Access.

Example Usage 3: Import and Export 3rd Party Module Data Many excellent third party modules exist that provide extended store functionality. However, many of these products do not contain an import/export function for configuration data. If the module allows configuration for each category or product, configuring it properly in a large store can be very time consuming using the Miva Merchant web interface. The Import/Export SuperMod allows the storeowner to export any database, including those from 3rd party modules! Now importing configuration data into any module database, regardless of the module vendor, can be accomplished!


Theory of Operation General Theory The SuperMod product line of modules for Miva Merchant are "super" because the products in this line give you control one layer above "normal" modules. As a result you can control settings, functionality and the interaction of other modules through the SuperMods. The SuperMods do not interfere with the functionality of other modules in your store - indeed they give you the ability to manipulate some of the functionality of those modules. Miva Script Database And Index Files Miva Script (the language Miva Merchant is written in) natively supports a database format known as “xbase”. In traditional xbase databases, all of the data is stored in one or sometimes two files for each database (ie: products.dbf and products.dbt). These files are stored in the mivadata directory on your web server. Miva Script databases are often “indexed”. Indexing a database provides data ordering and sorting capabilities, as well as provides fast search capabilities. The index files generally have a file extension of “mvx” (ie: prod_id.mvx) are stored within the same folder as the database files. Note: The name and location of the mivadata directory can vary from host to host, and is often called htsdata. Please consult your hosting provider for information on where your mivadata directory is located.) Some database applications can edit the xbase databases directly. However, most desktop applications such as Excel and Access do not always support all of the features of the database file format, and can cause data corruption. Further, the Miva Index files are a proprietary format, and cannot be opened or edited with any application other than a true Miva Script web based application such as Miva Merchant. For this reason, it is generally difficult to edit the database files for your Miva Merchant store directly. Xbase database files and their corresponding index files are not innately aware of one another. If a database file is edited directly and the corresponding index is not, the index file immediately becomes invalid since the records in the database have changed without the index being updated. Since the Miva Script index files are proprietary, there are no desktop applications that can edit a Miva Script database while keeping the indexes updated. When a database index is invalid, all searching and ordering of records for this database file will not function properly. This can cause a Miva Merchant store to stop functioning entirely! But there is a solution to the problem, described below. Xbase files are different than traditional text or spreadsheet files. When a record is deleted, it is not in fact removed from the files immediately. Instead, it is “flagged” for deletion. This means that even after a record is “deleted”, the file size will not change, and the index files will continue to reference the deleted record.


Database Packing There are two primary reasons to pack a database file. The first is to physically remove deleted records (rather, those that have been flagged for deletion), and the second is to refresh the database index files associated with the database. Miva Merchant provides two packing utilities, one for the domain and one for the store. Clicking on the “Pack Store” item in the left menu will pack all store (including 3rd party module) databases (ie: databases in the Merchant2/00000001 data directory hierarchy). This cleans out all deleted records and rebuilds all indexes associated with the database files for that store. Clicking on “Pack Domain” will perform the same process for the domain level databases (ie: all databases in Merchant2 directory). Note: Database packing is import to perform on a regular basis, and is imperative if the database files are ever edited or modified by hand (ie: not through the Miva Merchant administrative interface). Since editing databases by hand leaves the indexes in an invalid state, you should always pack the store and domain files immediately following any hand edits. Database Relationships The Miva Merchant administrative interface provides the storeowner with a controlled view of the databases within Miva Merchant. The interface has been written carefully to maintain data integrity and relationships, and in most circumstances will not allow the user to insert or delete data that could cause the system to stop working properly. This is very important, as the database relationships and data integrity are crucial to proper operation of the store. This is good but is also occasionally inconvenient. For the casual user, it provides a well-controlled environment in which to perform the basic administrative tasks in a deterministic manner. However, it can also be limiting (or at best tedious) when one needs to make a significant number of changes. The web-based interface often requires several clicks to change just a single piece of data. The Import/Export SuperMod gives you direct editing capabilities for all databases in your Miva Merchant store. While this provides maximum flexibility and will allow you to import any data into any database, extreme care must be taken to ensure that the data in your imports is both clean and correct! Many databases within Miva Merchant are “linked” to one another through the application logic. For xbase databases, there is no physical connection between any databases, so the linking of tables must be maintained through proper application coding. When editing databases directly, the application logic designed specifically to maintain data coherence is bypassed. Therefore, these relationships must be maintained by hand. For an in depth view of the database relationships within Miva Merchant, please consult the Miva Merchant database reference guide: http://www.miva.com/docs/api/db_HTML/MMdb4x.html Most module developers do not publish database reference guides for their modules. Extreme care must be taken to understand the relationships prior to importing raw data. The relationships can often be determined by examining the database files after configuring several items in the module.

http://www.miva.com/docs/api/db_HTML/MMdb4x.html


As an example of database relationship, we look at the products data for Miva Merchant. Please reference the products section of the Miva Merchant database guide at the following link: http://www.miva.com/docs/api/db_HTML/ch2.html#560724 From the image in the link, we see that the product “ID” field (often referred to as Products.d.id) is linked to 8 other tables: AvailabilityGroupXProduct, Upsell, UpsellXProduct, RelatedProducts, CategoryXProduct, PriceGroupXProduct, AttributesXProduct, and BasketsXProduct. This means that these 8 tables can be related to the products table, and they refer to a product by the ID field. Therefore, it is absolutely imperative that one never changes the ID of a product; otherwise any references to the product in question from any of the other tables will become invalid. Expert Tip: When a table name contains the “X” character, this generally implies it is a “cross” table. A cross table generally links two separate tables to provide a many-to-many relationship. For instance, the CategoryXProduct table links categories to products. Cross tables generally allow many-to-many relationships, as both of the linked tables on either side of the cross-table allow one-to-many relationships. For example, a category can have many products in it, and a product can exist in many categories. Expert Tip: In the database diagram referenced above, the type of connector used further specifies the relationship between the two linked tables. When one end of the connector contains “three connections” (ie: all but the Upsell/Product links are this type), this means that there is a one-to-many relationship established. From the diagram, we can tell that a product (referenced by the product ID) can exist in the CategoyXProduct table multiple times. Domain Keys and Store Keys Since many references between databases are maintained through the use of a database “ID” field, it is imperative that these IDs are always unique. For instance, the product ID uniquely identifies each product in the store. Occasionally, there are multiple unique fields for a table- such as the product code (though the product code is supplied by the user). Since the product ID is used to link to other tables, Miva Merchant generates this product ID internally (and it is generally not made available for viewing or editing through the Miva Merchant interface in order to maintain proper database coherence). Miva Merchant maintains a “key” database that allows the application to generate and use these unique IDs. There is a domain level key database for each Miva Merchant installation, and a store level key database for each store within the domain. These tables are generally found in the following locations, relative to the mivadata directory:

• Merchant2/keys.dbf • Merchant2/00000001/storekey.dbf

Note: The “00000001” directory is for the first store in the domain. This may differ for you.


When a user adds a product through the administrative interface, Miva Merchant will first check the current value of the Products store key. It will use this key as the unique product ID for the new product. It then increments the store key so that the next time a product is added, the key will again be unique. Keys should never be changed to a lower number; otherwise a previously used key will be used again. This can severely damage the database relationships and coherence. Expert Tip: Miva Merchant also uses “file locking” when accessing, using and incrementing the store key and domain key databases in order to avoid race-conditions. Race conditions exist when two users are trying to add products at the same time; if file locking were not used, it is possible that both users will get the same key before the other user increments the key. This would cause a “duplicate key” error. Expert Tip: In rare circumstances, the race condition is not properly avoided. In this case, a duplicate key may be used within your store. Generally when this occurs, they symptoms will be erratic or unpredictable store functionality. Duplicate key problems are found easily by packing the store and the domain; any duplicates will be reported as errors during the packing operation, since the indexes require the keys to be unique. When this happens, you can use the Import/Export SuperMod to export the database in question, find and remove the duplicate record, then import the database back into Miva Merchant. Note that a store and domain pack should be performed immediately following any Import/Export SuperMod import in order to have the database re-indexed properly. The importance of keeping keys unique cannot be understated. Since Miva Merchant maintains these keys internally, they are generally kept unique and up to date while you are using the Miva Merchant administrative interface. However, when you edit databases directly, Miva Merchant does not have the opportunity to ensure the keys are properly incremented. As a result, when importing any item that has a corresponding key (either domain key or store key), you must also update the key database to keep it up to date. For instance, if you import 500 products through a direct import, you must also edit your store-key database and set the Products key to 501. Otherwise you will not be able to add more products through the Miva administrative interface since it will try to use a key that is not unique. Miva Empresa / Miva Virtual Machine Timeouts The Miva Script program interpreter (Miva Empresa v3.x) or Miva Virtual Machine (Miva Empresa v4.x) that runs Miva Merchant has a built in configuration option for specifying the page-load timeout. For most installations, the timeout is configured somewhere between 30 to 90 seconds. This is the maximum time that a Miva Script program can run. Since most web pages should load in less than 5 to 10 seconds, a timeout value of 30 seconds is reasonable. If your pages take longer than 30 seconds to load, the web site visitor has probably already left and is not interested in waiting any longer for your page to load. The timeout is also important for preventing “runaway” processes that consume all of the server resources, but are stuck in a loop doing nothing. Miva Empresa will automatically terminate any page that has been running beyond the timeout limit.


While timeouts are a very important- and very necessary- feature of Miva Empresa, they present problems for database import and export operations. Though many databases are small and can be imported or exported in just a few seconds, some large database imports simply cannot be processed in the standard timeout duration. One solution is to increase (or even remove) the server timeout while performing imports or exports; however, this effectively removes the “runaway process” protection that the timeout feature was designed to prevent. Further, many common web browsers have a page load timeout built in as well. This can range from 2 to 5 minutes; even if the web server application (ie: import/export process) is still running after the browser timeout period, the browser will report a “page cannot load” error to the user. If the server timeout has been removed- the import process will continue until it is complete, while the user presumes it has failed! This is particularly troublesome during long-running imports, since the user presumes the import has failed and may try to start it again. This can end up with multiple “competing imports” running simultaneously, all competing for and using all of the server resources, and each potentially overwriting the others’ changes! It becomes evident that simply increasing the timeout to avoid import timeouts is not a good solution! The Import/Export SuperMod is “timeout safe”. During import or export, the SuperMod monitors the amount of time that has expired, and how much time is remaining before the server timeout. When it approaches the timeout, the Import/Export SuperMod will refresh the screen, effectively starting the server and browser timeouts over again, and the import or export will start again exactly where it left off.


Module Theory Data imports and exports are two of the most important features for any online system; unfortunately in the world of Miva Merchant, many import/export applications are poorly written and suffer from web server timeout issues. Further, the actual database files are often difficult to work with, requiring special database editing software. The Import/Export SuperMod solves this problem by allowing the storeowner to export any database to a common format that is readable by any text editor, spreadsheet or desktop database application such as Microsoft Access. The Import/Export SuperMod allows you to directly manipulate any database in the store, including those of 3rd party modules, through a comprehensive and robust import/export process. All databases can be exported or imported with a single click. Where many data import modules fail due to timeouts when importing large databases, the Copernicus Import/Export SuperMod excels. It can export or import any database of any size without suffering from browser or server timeouts. While exporting large databases can still be quite time consuming, all data exports will complete without interruption. However, due to limitations of the Miva Script language, there is a practical limit to the size of data imports; most if not all imports will be able to succeed. Since some very large imports cannot be fully processed, the Import/Export SuperMod provides an incremental import process that allows you to split an import into multiple files, importing each successively. Note on Terminology: Throughout this document, the terms “import” and “export” are used relative to the web server and your online store. Exporting data implies taking existing data from the store and putting it into a tab-delimited text file. Importing data implies taking data from a tab-delimited text file and putting it back into the store. Import/Export File Format The import/export files are tab delimited text files. Since all Miva Merchant data is generally used for web display, no records should contain the tab character (tabs are not displayed on a web browser; instead, they are translated into a single space, and successive spaces are further trimmed down into a single space on the displayed web page). Once the text file exports are created, they can be transferred from the web server data directory to the storeowner’s personal computer and edited with many different and readily available programs. After the files have been edited, they can be transferred back to the web server data directory and imported back into the Miva Merchant databases. The first line of every import/export file contains the field names. During a database export, the first line of the export file is pre-populated based on the existing fields in a database. During import, these field names must match the database field names exactly, or the import will not continue. Each additional line is the tab delimited data record, consisting of the “current” row of data. Empty fields are exported properly and tab delimited, so when the file is read into a text editor or


spreadsheet, all data columns line up properly. When importing these files into Excel, make sure to indicate that the first line contains the field names for the import. Database File and Export/Import File Names Databases in Miva Merchant have a file suffix of “dbf”. Some databases (though not all) also contain an extra “dbt” file that contains the “memo fields” for each record. The combination of a dbf and a dbt (if it exists) represents all of the data for an individual database. For instance, the entire product database for a store is contained within two files, products.dbf and products.dbt. During export, all data from both the dbf and dbt files are exported to the tab delimited file. The file suffix is replaced with “txt”. So the data export file for the products database would be called “products.txt” and is placed in the same data directory on the web server as the products.dbf. The products.txt file can be downloaded to a personal computer using FTP. Since the index files for Miva Script are proprietary and cannot be used by any other programs, the index files are not exported. However, after re-importing an edited database, the indexes can be rebuilt to match the imported data by packing the store (or the domain depending on what databases have been edited). Complete Exports and Incremental vs. Non-Incremental Imports During data export, all records for the current database are written to a tab-delimited text file. In the event that not all of the records can be exported during the server timeout period, the Import / Export SuperMod will refresh the screen (starting the timer over) and continue where it left off. The Import/Export SuperMod will continue to refresh as many times as is necessary to complete a full data export for all of the databases you have selected. Due to limitations of the Miva Script language, however, the import portion of the Import/Export SuperMod may not be able to read all of the lines of a very large import during the server timeout period. This is a technical limitation of the Miva Script language that cannot be worked around using Miva Script. The Import/Export SuperMod will process as much of the file your server timeout and server resources permit, refreshing the screen and continuing where it left of up to the point where it can no longer import additional lines. Under most circumstances- this will actually be when it has completed the full import, though on some very large databases or slow servers, this may occur at any point in your import file. After the import process has read as much of your import file as it can, the Import/Export SuperMod will continue on to the next file you have selected for import. The number of records imported will be indicated on the import screen. The module does provide a solution for these larger imports; it involves breaking the large database import into multiple files and processing each of them incrementally. The standard import mode for the Import/Export SuperMod is “non-incremental”. This means that all database records will be removed from the current online database prior to import. This


allows one to first export the entire database to a text file, edit the necessary records, and import the entire database back into Merchant. The current database is replaced with the contents of the text file. However, under certain circumstances generally relating to the speed of the web server and the length of the timeout period (as described above), there is a finite limit to the number of text file lines that can be read during the timeout period. Thus, the import cannot continue past this finite limit. In this rare circumstance, the module can be configured to process imports incrementally, which leaves all of the current data in the database while processing a new import file. In other words, the contents of the current database will NOT be removed prior to processing the import file. This allows you to split a large import into multiple files, process the first of the import files in non-incremental mode, then process each of the additional import files in incremental mode. Locked Databases Certain databases should not be modified using the Import/Export SuperMod unless absolutely necessary due to sever corruption. In particular, the AdminSessions database (the one that stores the current administrative session id) should never be modified using an import. If it is, the current administrator (usually the person using the Import/Export SuperMod) can be “kicked out” of the store due to loss of session information that is currently being used. While when this happens it is not fatal (one can always log back in), it would be surprising to the store owner or administrator (and even possibly cause undue concern) that they were kicked out of the Miva Merchant administration in the middle of a database import process! For this reason, any database can be flagged as a locked database. The Import/Export SuperMod will not allow imports of locked databases in order to prevent this from happening. By default, the AdminSessions (Merchant2/admsess.dbf) database is configured as a locked database. Any other database can be changed to locked or unlocked using the module administration page. Known Database Import/Export List When the Import/Export SuperMod is first installed, a default set of database file names is added to the “known database list”. This list is viewable in the Import/Export SuperMod tab of the store utilities. The default list contains all of the core Miva Merchant databases, as well as the MMUI and OpenUI databases. Other databases, for instance any 3rd party module database, can be added into the list of known databases at any time. Non-core databases can also be removed from the list. Note: Adding or removing database file names from the Known Database List does not affect the database files in your store. This list is merely a reference for the Import/Export SuperMod so it knows which databases to import or export. Adding items to this list, for instance 3rd party module databases, allows the Import/Export SuperMod to work with these databases. Removing items from this list will not delete the actual database files.


OpenDBv2 Enabled Import/Export The Import/Export SuperMod is an OPENDBv2 Advantage Module. When it is installed and configured for use with OPENDBv2, it will provide maximum performance for both imports and exports. OPENDBv2 Configuration: When OPENDBv2 is installed, the module will recognize this and look for an additional OPENDBv2 configuration variable called g.opendb_fullpath. This variable must be configured manually in the OPENDBv2 configuration file (cbssitevars) in the mivadata directory. The entry should contain the full directory path to the mivadata directory, since this cannot be determined at runtime. For example, the following entry in the cbssitevars file would enable direct SQL Imports and Exports for an OPENDBv2 store. The path should be modified to represent the fully specified path to your mivadata directory from the root of the file system.

g.opendb_fullpath=/full/path/to/ /mivadata OPENDBv2 Exports: When the OPENDBv2 configuration variable is properly set, the module will select and export up to 10,000 records through each cycle period. As soon as the module successfully exports the 10k records (or the timeout period is reached), the screen will refresh and the export will begin again following the last exported record. Under most circumstances, this will complete prior to the specified server timeout period, so the screen will refresh at a faster rate than normal. This export process should run approximately 5x to 10x faster than the normal (non-OPENDBv2 enabled) export. OPENDBv2 Imports: When the OPENDBv2 configuration variable is properly set, the module will perform data imports via the SQL command “LOAD DATA INFILE LOCAL”. This provides the most efficient import possible. On a reference test machine (a 600MHz Athlon with IDE drives), the Import/Export SuperMod can import over 100k product records in less than 5 seconds. Expert Tip: When using the LOAD DATA INFILE LOCAL method, the Import/Export SuperMod will import extra large databases in a single step. You may need to increase your server timeouts if the imports run too long; however, due to the way timeouts are determined and reported by the Miva Virtual Machine, database libraries are generally not “interrupted” due to a timeout. Even if a timeout occurs the command will likely complete successfully before the timeout is reported. Check the number of records in your MySQL database prior to attempting to import again. Note: Though the MySQL server documentation describes the LOAD DATA INFILE LOCAL command can be used without the MySQL Server FILE privilege, this does not appear to be the case for all MySQL server installations. If you receive permissions errors while running the OPENDBv2 enabled import, you will need to grant the FILE privilege to your MySQL user with the following command, substituting the proper username and hostname (usually localhost):

mysql> grant file on *.* to username@hostname;

Module Installation and Upgrading Domain Installation of Module You must first install the module in your Miva Merchant domain. After that you will need to follow the steps for installing the module in the store for which you have purchased the license. Module Domain Installation

1. Go into the Miva admin (admin.mv) 2. Open the Modules branch 3. Click on the Add Module link and the screen pictured below will appear 4. Click the Upload button

5. A Pop-Up window, like the one pictured below, appears and allows you to either Browse to find the module on your local drive or enter the filename of the module.

6. Press the Upload button


6. This is the Upload button

5. This is the Browse button

7. Once you press the Upload button, the Upload File PopUp box disappears and the Add

Module box is again visible. Press the Add button

8.


Now the module has been installed in the domain. Next you need to install the module in the store

7. This is the Add button

Store Installation of Module 1. Go to the Miva admin (admin.mv) 2. Open the Stores branch 3. Click on the arrow next to the store name 4. Click on Store Utilities Configuration 5. Check the checkbox next to the module name. (For this module it is CBS –

Import/Export SuperMod) 5. Click the checkbox next to the module name

67

89

1


. Press the Update button at the bottom of the screen.

. A PopUp box appears that looks like the picture below. Enter the Import/Export SuperMod license key you got when you purchased the module license.

. Read the License Agreement

. Check the box next to I ACCEPT THE TERMS AND CONDITIONS OF THE LICENSE AGREEMENT

0. Press the Update button. Now you have successfully installed the module in the storefront and you are ready to use it!

7. Enter the license key here

9.ag


10. Press the Update button

Accept the license reement here


Module Upgrading Copernicus publishes updates to its modules when there are significant feature enhancements. Copernicus also published upgrades to its modules for clients who are moving from uncompiled Miva Merchant to compiled Miva Merchant. Both updated and upgrades are added to the storefront in the same way. Once you have saved the update or upgrade to your local hard drive, please follow these instructions to add them to your storefront. Please note, when updating this module you may need to check the “Continue without interruption” box and click Submit. Domain Module Upgrading

1. Go to the Miva admin. (admin.mv) 2. Open the Modules branch 3. Click on CBS – Import/Export SuperMod module 4. Click on the Files link in the content area of the screen

4. Click on the Files link

5. Click on the Upload button

5. Click the Upload graphic button

6. The Upload file PopUp box will appear. Check the Overwrite box so that the updated module will overwrite the old version.

6. Check the Overwrite checkbox

7. Click the Browse button to find the file.

8. Press the Upload button

7. Enter the filename of the module on your local drive or use Browse to find the file. 8. Press the Upload button this will take you back to the “Files” screen. 9. Press the Update button and you are finished!

9. Press the Update button



Module Usage Module Configuration Once you have installed the module, you’ll want to configure it. The administrative interface for this module is located in the Store Utility Configuration section of the Miva admin:

1. Go to the Miva admin (admin.mv) 2. Click the arrow next to Stores. This will open up all of the stores you have in this

domain. 3. Click on the arrow next to the name of the store in which you have installed this module. 4. Click on the link “Store Utilities” and in the content area of the Miva admin, you will see

all of the tabs specific to the modules installed in this section. It will look similar to the picture below.

5. Click on the CBS – Import/Export SuperMod tab.

5. Click this tab to control the module configuration

CBS – Import/Export SuperMod Tab (Store Utilities Section) The Import/Export SuperMod is first configured in the CBS-Import/Export SuperMod tab in the Store Utilities Configuration section and then to perform the export and import functions, you will need to refer to the following sections that describe the “Export SuperMod – Export Tables

to Fllink. Mivaof dabuttodatabdatabfor elistinMerc


at File and Import SuperMod Import Tables to Flat File links underneath the Store Utilities In this main configuration tab you will find a listing of all databases that exist in your Merchant store – not including any third-party module databases. You can set the number tabases to display by changing the number in the display box and clicking on the “Refresh” n. In the picture above, the display box is set to 10. When searching for a particular ase to configure, remember to scroll through all of the pages of database listings since the ase you want to work with may not be on the first page. There are two configurable items

ach database that can be edited by using the white button at the far right of each database g. These options are described below. Additionally, some databases (non-core) Miva hant databases can be removed from the list.


• Delete?: Check this box if you would like to delete the database listed on this line from this listing. This will not delete this database from your Miva Merchant store. Instead, it will simply delete the name of the database from this list preventing the module from importing or exporting this database. If you delete a database from this list, the only way to add the database back into this list is using the yellow “Add Database” button in the blue bar at the top of the list. Note: The core Miva Merchant databases cannot be removed from the list; only extra databases (ie: 3rd party module databases or any others added by hand) will allow you to remove the database from the list.

• Database File: This is the file name and path to the database file relative to the mivadata root directory. This item cannot be modified.

• Incremental Import?: If you have a large database file that you plan to re-import

into your store, you may need to change this variable to “yes” and click Update. Please refer to the discussion on page 11 of this product manual regarding Incremental vs. Non-Incremental Importing to decide if you need to change this variable to “yes” or if you should leave this variable as “no.” This variable is set to “no” by default since few users will actually need to incrementally import their data.

• Locked?: Certain types of databases should not be imported or “re-imported” into Miva Merchant; therefore, this variable allows you to flag those databases so that they are locked and cannot be imported. To flag a database as locked, change this variable to “yes” and click Update. For a completed discussion of flagging a database as locked, please refer to page 12 of this product manual. When a database is “locked” in this tab, then it will not be made available for import in the Import SuperMod: Import Tables from Flat File link.

Add a Database: When you add a new module that contains a database to Miva Merchant and you want to be able to import or export data from the module databases, you need to make the Import/Export SuperMod aware of the existence of the module databases. To do this, click on the yellow “Add Database” button in the CBS-Import/Export SuperMod tab. Then type into the full database file path and name into the database file text box. The path should be fully specified relative to the mivadata directory. Then click Update. If you do not know where your mivadata directory is located, please consult your hosting provider. (Please note that this directory is sometimes also referred to as the “htsdata” directory.) If you have not entered the correct path or you have identified the database incorrectly, you will receive this error message: “The database specified does not exist.” You will need to modify the path or filename to properly identify the name and/or location of the database file.

To add a database to the list, click on the Add Database button.


Add the database name and directory here


Export SuperMod: Export Tables to Flat File (Below Store Utilities Section) It is from this link that you will initiate the export process for a database. The module reads the .dbf database files and exports them into text (.txt) files and saves the exported files in the same directory as the database (dbf) file. You can then download and edit the .txt file. For example, if you export the Merchant2/00000001/products.dbf file, you will find the exported database as Merchant2/00000001/products.txt. To edit the .txt file, you can use any application that accepts tab-delimited files, such as Notepad, Excel or Access. Make your edits directly to the text file. (Please refer to the General Theory and Module Theory sections of this product manual for an explanation of why you would want to edit a database.)

Every database that is listed in the CBS-Import/Export SuperMod tab is listed in this section of the module. The four columns of the screen are described below.

• Export? Check the box if you want to export the data in this database. To toggle all of the boxes on or off, click on the Check All and Uncheck All boxes at the bottom of this screen. If you only want to export one database, toggle the Uncheck All box and then check the “Export?” box only for the database to be exported.


• Last Export? This variable records the date and time (in the time zone of your server) of the last export of this database. If the database has not yet been exported, the variable will list “Never” as the Last Export date.

• # Records: This is the total number of records currently in the database, including any deleted records. If you have packed your store and domain immediately prior to export, this will be equal to the number of lines exported. However, the export process will only export non-deleted records, so the number of lines in your export file may be less than the number of records indicated here..

• Path: This is the name of the database to be exported, relative to the root mivadata directory.

Note: You may see a line item in this section that appears gray instead of black. This means that the database files do not exist and therefore cannot be exported. This typically occurs if another database file is being used in place of the one that is “gray.” That is, for users of the OpenUI, all OpenUI database files will be black and available to be exported; whereas, the MMUI database files will be “gray” and cannot be exported. This is correct and should not cause concern since a storefront using the OpenUI will not, by definition, use the MMUI database files.


Import SuperMod: Import Tables from Flat File (Below Store Utilities Section)

Once you have exported a file and made changes to the file, you will need to Import it back into your Miva Merchant store. Although you may have edited the file in Excel or Access, you must return the edited file to its “.txt” extension (tab delimited file) to import it back into your store. After editing the file, it should be FTP’d back into the same location from where you originally retrieved it.

Note: You must then be sure that upon completion of those edits, you save the file again as a tab-delimited text file including the first line with the field names, and replace the .txt file in the mivadata directory with the newly edited .txt file. (Depending on the application you use to edit the .txt file you may need to import the .txt file into that application and when you are finished making changes, export the file to a .txt file. Please consult the product documentation for your application of choice to determine this importing and exporting process.)

It is from this link that you will initiate the Import of the altered file back into your store. This screen “remembers” those database files that have been exported and not yet imported; therefore, when you click on this screen you will see the “Import?” variable pre-populated with a check in the box for those databases that you have exported but not yet re-imported. You can only import those databases that have previously been exported (ie: the tab-delimited text file of the proper name exists). If you have multiple databases that need to be imported but you are only prepared to import a subset of those databases, you can toggle the Check All and Uncheck All boxes and select only the desired import files.

Note: Databases that appear gray on this screen are either locked or a corresponding text import file does not exist in the proper directory.

Evethe


ry database that is listed in the CBS-Import/Export SuperMod tab is listed in this section of module. The four columns of the screen are described below.

• Import?: Check this box if you would like to import this database. Multiple databases can be selected for import at the same time.

• Last Export: This variable records the date and time (in the server time zone) of the last export of this database. If the database has not yet been exported, the variable will list “Never” as the Last Export date.

• # Records: This is the current number of records in the database, including any deleted records. When the database is re-imported, this number may change and it will reflect the number of records that were imported with this database. Note: For non-incremental imports the database is cleared prior to import, including all deleted records. Expert Tip: Following the import, the number of records should be equal to the number of records in your import file. If this is not the case (ie: fewer records imported than are in the import file), please consult the section above regarding incremental imports. You will need to switch this database to an incremental import, and re-import the remaining records (ie: the portion of your import file following the last number of imported records).


• Path: This is the path to the .txt file relative to the mivadata directory. Be sure that the newly modified database replaced the exported database in the folder to which this path leads. Otherwise, you will import the “old” (i.e. exported) database.

Please note: You may see a line item in this section that appears gray instead of black. This means that there is no text file available for import for this database or the database is flagged as “locked”.


Legal Information Copyright Information This document and the software described by this document are protected by copyright law. (Copyright © 2002 - 2004 Copernicus Business Systems, LLC. All Rights Reserved.) This document and the software described herein are the property of Copernicus Business Systems, LLC. Use of this document and the software is restricted to the specific terms and conditions in the License Agreement associated with the software. Duplication or distribution of this document or portions of this document for uses not covered by the License Agreement is not allowed without a written agreement signed by an officer of Copernicus Business Systems, LLC. Information contained within this document is subject to change without notice. THE SOFTWARE DESCRIBED IN THIS DOCUMENT WAS DESIGNED TO SUPPLEMENT SOFTWARE AND/OR OTHER PRODUCTS PRODUCED AND/OR PROVIDED BY MIVA CORPORATION. COPERNICUS DOES NOT ENDORSE AND IS NOT AFFILIATED WITH MIVA CORPORATION, AND DOES NOT CONTROL MIVA PRODUCTS. COPERNICUS IS NOT RESPONSIBLE OR LIABLE FOR ANY UPGRADES, UPDATES, ENHANCEMENTS OR FUTURE RELEASES OF MIVA CORPORATION SOFTWARE OR PRODUCTS THAT MAY BE INCOMPATIBLE WITH THE SOFTWARE OR RENDER THE SOFTWARE INEFFECTIVE. COPERNICUS DOES NOT WARRANT THAT THE SOFTWARE WILL WORK EFFECTIVELY WITH ANY UPGRADES, UPDATES, ENHANCEMENTS OR FUTURE RELEASES OF MIVA CORPORATION SOFTWARE OR OTHER PRODUCTS. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL COPERNICUS BE LIABLE TO CUSTOMER FOR ANY INCIDENTAL, SPECIAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES OF EITHER CUSTOMER OR A THIRD PARTY AGAINST CUSTOMER (INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR INFORMATION, LOST PROFITS, BUSINESS INTERRUPTION OR OTHER PECUNIARY LOSS) ARISING OUT OF OR IN CONNECTION WITH THIS SOFTWARE OR USE OF OR INABILITY TO USE THE SOFTWARE EVEN IF COPERNICUS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL COPERNICUS BE LIABLE FOR DAMAGES FOR ANY CAUSE WHATSOEVER (WHETHER BASED IN CONTRACT, TORT OR OTHERWISE) IN EXCESS OF THE AMOUNT PAID TO COPERNICUS BY CUSTOMER FOR USE OF THE SOFTWARE. SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU. OPENxb and Copernicus Business Systems are registered trademarks of Copernicus Business Systems, LLC. The Copernicus Revolution, RMXB Technology, Celestia and related images are trademarks of Copernicus Business Systems, LLC. Miva is a registered trademark of Miva


Corporation. Miva Script, Miva Merchant, Miva Empresa, and the Miva Engine are trademarks of Miva Corporation. OpenUI is a trademark of the OpenUI Developer’s Consortium. MySQL is a trademark of MySQL AB. All other trademarks are the property of their respective owners.


Corporate End User License Agreement YOU SHOULD CAREFULLY READ ALL THE TERMS AND CONDITIONS OF THIS AGREEMENT PRIOR TO USING THE SOFTWARE. USE OF THE SOFTWARE INDICATES YOUR ACCEPTANCE OF THESE TERMS AND CONDITIONS. COPERNICUS BUSINESS SYSTEMS, LLC (“LICENSOR”) IS WILLING TO LICENSE THE SOFTWARE TO YOU ONLY IF YOU ACCEPT THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT. IF YOU DO NOT AGREE TO THESE TERMS AND CONDITIONS, ERASE ALL COPIES OF THE SOFTWARE, DOCUMENTATION AND ALL OTHER COMPONENTS OF THE SOFTWARE FROM YOUR COMPUTER’S MEMORY AND CERTIFY TO LICENSOR THAT YOU HAVE DONE SO WITHIN SEVEN (7) DAYS OF DOWNLOADING THE SOFTWARE.

1. Grant of License. Licensor hereby grants to you (“Customer”) a non-exclusive, non-transferable license to use the Software solely in accordance with the terms of this Agreement. For the purposes of this Agreement, “Software” means the software programs and documentation accompanying this Agreement and any online documentation. This Agreement permits Customer to use one copy of the Software on one MIVA Merchant Domain (“Domain”) and on one Store within that Domain. Customer may make one copy of the Software for archival and backup purposes. Customer must reproduce and include any copyright and trademark notices, legends and logos on each copy of the Software or diskettes made by Customer. The Software is protected by copyright laws and international copyright treaties and other laws regarding trade secrets and other intellectual property rights. Title and full ownership rights to the Software and any and all copies of the Software remain with Licensor.

2. Use of Software. Licensor will provide Customer with a license key to activate the Software. The Software may be used only for, by, and on behalf of Customer. Customer may not transfer any of its rights hereunder.

IN NO EVENT MAY CUSTOMER TRANSFER THE SOFTWARE TO ANY PERSON, ENTITY OR OTHER END USER IN VIOLATION OF APPLICABLE U.S. EXPORT LAW, INCLUDING, BUT NOT LIMITED TO, ANY TRANSFER FOR USE OUTSIDE THE COUNTRY IN WHICH IT WAS ORIGINALLY LICENSED.

3. Term and Termination. This Agreement may be terminated by mutual consent, or by election of either Customer or Licensor in case of the other’s unremedied material breach. In case of any termination of this Agreement, Customer will immediately return to Licensor all the Software components that Customer has obtained from Licensor and any copies in Customer’s possession, and will certify in writing that all such components and all copies of the Software have been returned or destroyed, and all copies erased from the memory of Customer’s computers.

4. Disclaimer of Warranties.

4.1 Licensor does not warrant that the functions contained in the Software will meet Customer’s requirements or that the operation of the Software will be error free. The Software is licensed on an “AS IS” basis. The entire risk as to the quality and performance of the Software is solely with Customer.


4.2 NO OTHER WARRANTIES, EXPRESS OR IMPLIED ARE MADE WITH RESPECT TO THE SOFTWARE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THIS EXCLUSION MAY NOT APPLY TO YOU.

4.3 YOU UNDERSTAND THAT THE SOFTWARE WAS DESIGNED TO SUPPLEMENT SOFTWARE AND/OR OTHER PRODUCTS PRODUCED AND/OR PROVIDED BY MIVA CORPORATION. LICENSOR DOES NOT ENDORSE AND IS NOT AFFILIATED WITH MIVA CORPORATION, AND DOES NOT CONTROL MIVA PRODUCTS. LICENSOR IS NOT RESPONSIBLE OR LIABLE FOR ANY UPGRADES, UPDATES, ENHANCEMENTS OR FUTURE RELEASES OF MIVA CORPORATION SOFTWARE OR PRODUCTS THAT MAY BE INCOMPATIBLE WITH THE SOFTWARE OR RENDER THE SOFTWARE INEFFECTIVE. LICENSOR DOES NOT WARRANT THAT THE SOFTWARE WILL WORK EFFECTIVELY WITH ANY UPGRADES, UPDATES, ENHANCEMENTS OR FUTURE RELEASES OF MIVA CORPORATION SOFTWARE OR OTHER PRODUCTS.

5. Limitation of Liability. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL LICENSOR BE LIABLE TO CUSTOMER FOR ANY INCIDENTAL, SPECIAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES OF EITHER CUSTOMER OR A THIRD PARTY AGAINST CUSTOMER (INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR INFORMATION, LOST PROFITS, BUSINESS INTERRUPTION OR OTHER PECUNIARY LOSS) ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT OR USE OF OR INABILITY TO USE THE SOFTWARE EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL LICENSOR BE LIABLE FOR DAMAGES FOR ANY CAUSE WHATSOEVER (WHETHER BASED IN CONTRACT, TORT OR OTHERWISE) IN EXCESS OF THE AMOUNT PAID TO LICENSOR BY CUSTOMER FOR USE OF THE SOFTWARE. SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU.

6. Other Restrictions and Limitations. Customer agrees that (1) it will not copy the Software except as permitted in Section 1; (2) it will not reproduce, deactivate, or bypass any security device supplied with the Software; (3) it will preserve and respect Licensor’s copyright and the notice of copyright included in the Software; (4) the Software contains information which is confidential and proprietary to Licensor, and Customer will not disclose or transfer or otherwise provide to any third party all or any part of the Software without the express written consent of Licensor; (5) it will not disassemble, reverse compile or reverse engineer the Software or any portion thereof or otherwise attempt to discover the source code or structural framework of the Software; (6) it will not rent or lease the Software; and (7) it will not modify the Software.

7. Breach. Customer will be deemed to be in breach of this Agreement if Customer violates any covenants or obligations imposed on it under this Agreement.

8. License by U.S. Government. The Software is provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the U.S. Government is subject to restrictions set forth in 48 CFR 52.227-14


(g)(3)(ii) as applicable. Contractor/Manufacturer is Copernicus Business Systems, LLC, 2545 Haddenham Lane, Smyrna, GA 30082.

9. General Terms and Conditions. The terms and conditions of any purchase order or other ordering document issued by Customer in connection with this Agreement which are in addition to or inconsistent with the terms and conditions of this Agreement shall not be binding on Licensor and shall not be deemed to modify this Agreement. This Agreement constitutes and expresses the entire agreement and understanding between the parties in reference to all matters referred to herein and any and all previous agreements, discussions, promises, representations, and understandings between the parties relative thereto are merged herein and superceded hereby. The remedies provided in Section 3 shall be cumulative and additional to any other remedies in law or equity which Licensor may have. This Agreement shall be governed by the laws of the State of Georgia and shall inure to the benefit of Licensor, its successors, and assigns. The sole jurisdiction and venue for any litigation arising out of this Agreement shall be an appropriate federal court in the Northern District of Georgia or a state court located in the Northern District of Georgia. Customer hereby consents to personal jurisdiction in such courts. Sections 4, 5, 6, 8 and 9 shall survive any termination of this Agreement. All rights not specifically granted herein are reserved by Licensor. 10. Customer understands and agrees that by agreeing to this License, You are "opting in" to a mailing list. Copernicus Business Systems will use information supplied by You to contact You with marketing and technical information in a variety of ways including, but not limited to, electronic mail, postal mail, telephone and fax. If You do not wish to receive marketing and/or technical information from Copernicus Business Systems, You may use systems provided by Copernicus Business Systems to "opt out" of the mailing list.

search engine tracker for miva merchant

Documents