Quick question. Anyone know if MvTRANSACTION is still supported by the mivascript API and if it follows a similar paradigm to MySQLs transaction? Also a related question, I've noticed that hardly anyone uses any other DB format other than MySQL, yet Miva heavily relies on it's own mechanism for iterating id numbers. Is there a reason for this? Would it be bad practice to say create a table with AUTO_INCREMENT field? Or to create a table with NOT NULL/NULL on a specific fields? Any thoughts would be very helpful.
Announcement
Collapse
No announcement yet.
DB Questions
Collapse
X
-
Re: DB Questions
MvTRANSACT, MvCOMMIT and MvROLLBACK are still supported for MySQL, but are disabled by default. You will need to issue two MvDBCOMMAND tags to enable them:
Code:<MvDBCOMMAND NAME = "db" COMMAND = "manualcommit"> <MvDBCOMMAND NAME = "db" COMMAND = "transactions">
-
Re: DB Questions
As a data point, we abandoned MivaSQL entirely more than two years ago and use auto_increment for all our internal ID fields. We also use not null and unique.Last edited by Gordon - Phosphor Media; 12-11-14, 06:26 PM.Gordon Currie
Phosphor Media - "Your Success is our Business"
Improve Your Customer Service | Get MORE Customers | Edit Any Document Easily | Free Modules | Follow Us on Facebook
phosphormedia.com
Comment
-
Re: DB Questions
Is MivaSQL still supported? I thought it had been end-of-life'd, or was scheduled for that in the near future?
Thanks --Kent Multer
Magic Metal Productions
http://TheMagicM.com
* Web developer/designer
* E-commerce and Miva
* Author, The Official Miva Web Scripting Book -- available on-line:
http://www.amazon.com/exec/obidos/IS...icmetalproducA
Comment
-
Re: DB Questions
Yes, MivaSQL is still supported (and will be for the foreseeable future). With that said, it's mostly academic, you should really never run Miva Merchant that way (it's not PCI compliant for one thing).
The reason we keep supporting MivaSQL is it "keeps us honest" if you will, in making sure our language can be easily ported between SQL's at will on our end and that we don't end up married to unique items in one form of SQL over another.
Comment
Comment