Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

I would like to migrate a web application that uses PHP PDO and MySQL as a data backend. I have no prior SQL Anywhere or Sybase experience.

Possible Design 1

SQL Anywhere -> ODBC -> PHP PDO -> Web Application

Possible Design 2

SQL Anywhere -> SQL Anywhere PHP Module -> Web Application

What are the merits and limitations of each design and how well are they supported? Is there a better approach? Which downloads and documentation links do I need to get started with each approach?

It was hard from an online search to tell which links and documentation are most up-to-date and relevant. Are my assumptions below correct?

asked 02 Nov '12, 11:39

MMacdonald's gravatar image

MMacdonald
1766617
accept rate: 0%

edited 15 Mar '13, 21:06

Mark%20Culp's gravatar image

Mark Culp
24.9k10141297


Just a few comments - I've only used PHP/SQL Anywhere for some testing...:

  • Your first assumption is true - however, this is restricted by license agreements... - for only web-based development, you might prefer to use the free SQL Anywhere Web edition:)
  • Can't tell on PDO
  • Yes, the PHP module is a native driver - it is (like the Perl, Ruby and Python drivers) based on the SQL Anywhere C API
  • AFAIK, your fourth assumtion is true, too.

Have you read the following whitepaper? (It deals with v11 but should work with v12, too)

Getting Started with SQL Anywhere and PHP

And there's the particular SQL Anywhere PHP Developer Center


Whether you prefer to use the native SQL Anywhere driver or PDO might also depend on the question how much code must be adapted - AFAIK, the native driver uses SA-specific functions like sasql_connect() and therefore you will need to adapt your MySQL function calls, methinks. On the other hand, native MySQL function calls are different from usual PDO calls, too, so in case you have not yet used PDO at all, you will inevitably have to change function calls (and possibly queries, too)...

permanent link

answered 02 Nov '12, 12:08

Volker%20Barth's gravatar image

Volker Barth
40.2k361550822
accept rate: 34%

Because we already use ODBC, I'm trying the PDO/ODBC approach. Having a database abstraction layer seems generally smart, and PDO is widely used in the PHP community.

(05 Nov '12, 07:13) MMacdonald
Replies hidden

FWIW, I hope you get better/more feedback on your questions w.r.t. the documentation and the PDO way - I'm very faaar from being an experienced resource here:(

(05 Nov '12, 07:56) Volker Barth
1

This is the approach I took. It was much easier to find examples when searching for PDO/ODBC.

Also, related software that you might want to incorporate will be able to handle the generic PDO/ODBC setup, where you may be on your own trying to get it to connect through the php module.

(13 Nov '12, 15:26) Siger Matt
1

PDO is a fine way to go if you already using PDO ODBC. As far as the 'native' php driver, the functions are pretty standard, so for migration, a search and replace of "mysql" with "sasql" in your php code would get you there. The only other thing I can think of as something to consider (aside from the benefits of abstraction provided by PDO) is that you would probably get better performance out of the native SA php driver.

(15 Nov '12, 13:42) Jason Hinspe...
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×70
×25
×5

question asked: 02 Nov '12, 11:39

question was seen: 3,003 times

last updated: 18 Apr '17, 17:00