If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Importing data in that manner should be possible, but interacting with a store database directly is not advised given it conflicts with PCI guidelines, may create problems that are not immediately apparent, and recovery from a mistake made in that manner, short or long term, may involve billable hours if the database in question cannot be restored in its entirety due to a need to keep data, or it being too far out to perform such a restore. Long term, this type of access is being eliminated for those reasons and a few others related to availability / scalability.
The API would be the preferred method to push raw data in if a store data import isn't applicable to the situation.
Good info about the future. Also, appears the Miva stores need an accessible 3rd Party DB/Table capability.
Following up with this question then. I was importing the SQL table directly into the Miva Store DB to save some coding cost. This table will only be read from and there currently no intent to write to these tables. What about creating an independent DB and importing the table into this new DB? Then I could read the data from the independent DB/Table? And of course, there is no interaction with the Miva store tables.
Would I need owner permissions to create the DB/Tables to import to?
That sounds like a good plan; MivaScript code, or a helper module, etc. would let the other db be queried with the credentials set in the store, module, template, etc. Any database user created in the control panel and attached to a given database should have full permissions on that database short of MySQL admin-level.
Comment