Update 3/20/17: For new accounts, Stripe is requiring TLS 1.2. The CURL library I’m using to talk with Stripe appears to support only TLS 1.1. Until this is figured out, StripeX will NOT work with new Stripe accounts. It continues to work with OLD Stripe accounts. Sorry for any trouble. Hopefully I can track down a solution.
I’ve released a new version of StripeX on VFPX. This version adds several Card functions that allow you to save a credit card to a customer. This is handy for setting up subscription (which I’ll be adding next to StripeX) or if you need to routinely charge a card for a customer. The new methods are:
CardCreate() – Adds a credit card to a customer
CardDelete() – Deletes a credit card from a customer
CardLIst() – Builds a cursor of all the credit cards on the customer
CardRetrieve() – Retrieves information for a particular card
ObjectExtract() – Is a new utility method that retrieves a value from Stripe objects. You can use that, for example, to retrieve the information from the CardRetrieve() method
Here’s some sample code using those functions. It creates a new card for a customer, gets a list of existing cards, retrieves the first card found, prints some info for that card, and then deletes the card that was added card.
For a while, I’ve had a simple little debug class that let’s me output messages to the debug window or to a text file. For example in my application that sends an email, if the sending fails for some reason, I create a little text file the user can send me:
oDebug = newobject(“DebugX”)
oDebug.Message(“Email address was: ” + oMail.cSendTo)
oDebug.Message(“Error message was: ” + oMail.cErrorMsg)
This class has a couple little interesting features:
- As noted, the message function can send to the debug window or to a text file. Just set the .cOutputType property.
- Every .Message() gets a date + time stamp so I know when it happens.
- I know this never happens to you, but I sometimes forget to remove the debug code before sending to production. This class has a lIsDevelopement property. If it’s not developement, then the .Message() doesn’t do anything.
Tamar‘s talk about speeding up Foxpro code at Southwest Fox prompted me to add a couple new functions:
- Added a .Start() and .Stop() to start/stop a timer. Any .Message() that is sent while the timer is going will include the elapsed seconds. This works correctly over Midnight as well.
- Added a .Loop() function that will loop a .nLoop number of times. This is handy if one pass through your code is not enough to accurately time how long it takes. If you accidentally leave this code in for production, nLoop always resets to 1.
So you can do things like:
oDebug = newobject(“DebugX”)
oDebug.Start(“Start timing some code, Loop 4 times”)
oDebug.nLoop = 4
do while oDebug.Loop()
oDebug.Message(“Pass # ” + tran(oDebug.nLoop))
<some Foxpro code I want to time >
oDebug.Stop(“End of debugging test”)
Here’s the code:
One of the most interesting things I saw at Southwest Fox was Tuvia’s presentation of dbSchema (see his white paper for all the great things about dbSchema). I rushed home, got it installed, and … ran into some issues. It’s still a great tool that I’ll be using, just not quite as great as I hoped. Here are the issues I’ve run into:
In theory: With dbSchema, I’ve got one schema for my development database and then at the client I’ve got a schema for the production database. When I’m ready to go live, I just compare the two schemas and it’ll show me the differences and update my production database.
In reality: dbSchema is reporting a lot of differences that don’t appear to be differences:
This might be because my development server is SQL 2012 while the client is SQL 2005. Maybe if I went ahead and made those changes, the differences would go away. I haven’t been brave enough though to make a couple thousand changes to the production database.
I had hoped this would be automatic, instead I have to hunt through this list to find the actual changes. Still better than having to remember the changes or document them as I develop.
dbSchema has a great tool called Layouts that you can use to document your database. It can show what tables are linked to what, what the keys are, add comments, etc. My client in this case is pretty tech savvy and I was excited to do the Layouts in development and then synch them up to the production schema.
Alas, the compare schema function does not synch the layouts. I can’t find a way to export/import a layout from one schema to another.
You could get around this by having just one schema – just replace the production one, but that then erases any work the client did.
dbSchema has a cool tool that exports all of your layouts to HTML which is nice. Each layout goes to a separate HTML page. There is not an index page or a way to navigate from one page to another page though. Minor annoyance.