Equivalent to WITH clause in Sybase ASE - sybase-ase

It appears that WITH is supported only in Sybase SQL Anywhere:
...but not in Sybase ASE :(
Can someone suggest if there is a equivalent construct in Sybase ASE? There are other ways to implement stuff instead of using WITH, but we are planning to repurpose some of our dynamically generated SQLs to run in Sybase and support for WITH or something close to that syntax is very much desired.

ASE doesn't have support for common table expressions (eg, WITH clause).
The (obvious) workarounds would be #temp tables, views, materialized views (aka precomputed result sets), table variables (ASE 16.0 SP02+), and in limited situations possibly derived tables and/or (correlated) sub-queries.
NOTE: I don't work with SQL Anywhere so not sure if this is technically doable but fwiw ...
I'm thinking there's probably a way to setup a proxy table from SQL Anywhere to ASE, with the idea being to run your CTE/WITH query from within SQL Anywhere.
'course, even if that's technically possible you're looking at the extra overhead for maintaining the SQL Anywhere database, and the performance for such interserver queries would likely be unacceptable (eg, pulling all the data from ASE into SQL Anywhere to, in effect, materialize the CTE).


What databases used with PHP share the same (or most) of the SQL syntax?

I've read that although SQL is meant to be standardised, it is implemented different etc with different databases. I have only ever used MySQL for databases.
What I would like to know is what other databases share the same syntax? I am using PDO now, and I would like to set a flag to allow the user to specify which database they would like to use.
I would be interested in knowing which are the 'safe' databases that will handle most (if not all) my general MySQL queries. Mainly SELECT, INSERT, UPDATE, DROP, DELETE.
There are several revisions of a such called ANSI SQL.
All major database engines (that is Oracle, MS SQL, PostgreSQL and MySQL) should (should) in theory support SQL-92.
This includes everything you've mentioned: SELECT, INSERT, UPDATE, DROP, DELETE, as long as you don't use complex clauses with them.
In practice:
Not all databases support the full set of SQL-92.
Writing cross-platform SQL even in SQL-92 requires lots of testing.
Platform independency in SQL ends when you insert your 1001st row and need to optimize you queries.
If you browse a little over StackOverflow questions tagged SQL, you will see that most of them say "help me to optimize this query", and most answers say "use this platform dependent hack"
You will find that some database store datatypes differently, for example, mysql stores Booleans as 1 and 0 and postgres stores them as 't' and 'f'.
As long as your database classes are aware of the need to convert data, you should be fine, probably 96.3482% of everyday CRUD will work pretty well across the board.
Even if you create database classes that directly call PDO, you can later on add some logic for data translation or query modification.
You could use the database abstraction layer ADOdb. (its got what plants crave)
I'd suggest making sure that your customers actually give a crap about which database they need to run before you spend a lot of time developing functionality you may not need.
A standardized SQL92 is pretty much the same in all RDBMS. The differences are in parts, that the standard doesn't define, like for example LIMIT or datetime handling functions and of course procedural languages.
As for DBs popular with PHP: it not that hard make SQL portable between MySQL, SQLite and PostgreSQL. It won't be that easy with Oracle, Sybase and DB/2.

Should a PDO script written for MySQL work with Oracle? [closed]

I understand that in general PDO scripts are cross compatible i.e. generally changing the connection string should work.
In the past I've spent hours searching online after changing a PDO script connection string from MySQL to SQLite as this isn't the case, some things don't work the same (I remember an issue with row counting or something).
So should changing from MySQL to Oracle be generally simple, or are there things to watch out for as in the SQLite case?
So should changing from MySQL to Oracle be generally simple, or are there things to watch out for as in the SQLite case?
There are things to watch out.
More seriously, beside basic SQL query, each RDBMS has its own set of specific features that have to be taken into account. Just to give one example, if you want to limit the result set to one row only, MySQL provides the LIMIT clause. But for Oracle up to 11g, you need a sub-query for that purpose.
If you really need cross-vendor support, you probably should take a look at some library providing database abstraction layer whose job is to allow you to write database-agnostic code. PDO isn't such a library. But Doctrine DAL, Zend_db and many other are.
It is now considered as off-topic to request suggestions for a tool here, but take a look at this old question if you need few pointers: Best PHP DAL (data abstraction layer) so far

Created Temporary Tables Dynamically

I have scenario like, I need to create a stored procedure in which the columns will come dynamically. Based upon this columns temporary tables should be created.
Actually, this scenario I did in SQL Server and I have migrated the SQL Server database to Oracle.
If you want to create a table dynamically, you'd need to use dynamic SQL
EXECUTE IMMEDIATE 'CREATE GLOBAL TEMPORARY TABLE table_name( col1 number, col2 number )';
That being said, it is almost certainly a mistake to directly port SQL Server code that creates temporary tables to Oracle. It will not work the same way that your SQL Server code does.
First off, temporary tables in Oracle are visible to every session unlike SQL Server where they are local to the session. That means that if you have two sessions calling your stored procedure, they'd both try to create the temporary table and the second one would fail (things get worse assuming that you are also dropping the temporary table at the end of the procedure rather than letting thousands of temporary tables accumulate).
Creating tables is an inefficient process in Oracle given the amount of latching that is required. Oracle's assumption is that you are not creating objects on the fly. If your application violates that assumption, you will encounter some scalability issues.
If you create tables on the fly, you'll have to refer to them on the fly. So any queries against the temporary tables will also need to use dynamic SQL. That is less efficient than static SQL and it makes your code harder to write, harder to debug, and harder to maintain.
Maybe I'm bit of-topic but try to analyze what are you really want to achieve. I've been working with several people who used T-TSQL and the patterns used in SQL server are different from Oracle ones. Simply do not try to exactly rewrite your code one to one.
It will not work.
For example usage of temporary table is considered to be a bad design in Oracle(in most cases). In cases where you use temp tables in T-SQL you will usually use cursors in Oracle.
Also keep in mind that SQL and PL/SQL are compiled languages(it's not real scripting). You can not (re)create a table in a PL/SQL package and then use it in the some (or other package).
When you modify an object in Oracle all the depending code has to be recompiled in background.
This is a source of many frustrations for the people who come from SQL Server onto Oracle.
It's not worse, it's just more different than it seems to be.

Use common table expression query

I have a common table expression which works fine on the mssql editor. However, when I use the same populating a string variable in PHP and using odbc_exec($dbhandle,$query ) it returns no rows. No error is thrown. Is this a limitation on PHP? Other select queries on various other tables run fine. Issue is only with the CTE statement.
I know this is an old question, but it wasn't answered and it's a high ranking Google result so I thought I'd chip in.
None of the native PHP methods of querying an MS SQL server can support Common Table Expressions ('WITH' clauses). These include the mssql_* libraries AND the odbc_* libraries.
This is due to the way MS SQL handles it's CTE's (by creating macros for execution). The good news is that Microsoft's libraries (sqlsrv_*) DO support CTE's natively.
The sqlsrv_* libraries operate identically to mssql_* in terms of creating and consuming connections, simple queries, prepared statements etc. They are almost a 'drop-in' replacement for using mssql_* or odbc_* with MS SQL servers, and are significantly faster to boot.
You can obtain the sqlsrv libraries from this link. As of this writing, 2.x is fine for SQL 2008, but 3.x is needed for SQL 2012.

Is it preferred to create tables in mysql using a third party application (phpmyadmin, TOAD, etc…) versus php?

Is it preferred to create tables in mysql using a third party application (phpmyadmin, TOAD, etc...) instead of php?
The end result is the same, I was just wondering if one way is protocol.
No, there isn't a 'set-in-stone' program to manage your database and query to it.
However, I highly recommend MySQL Workbench.
It allows you to graphically design your database, query to your database server and do all kinds of administration tasks.
I'd say it is far easier to do so within an application created for that purpose. The database itself obviously doesn't care as it's just DDL to it. Using Toad or PHP MyAdmin would help you do the job quicker and allow you to catch syntax errors prior to execution or use a wizard where you're not writing it by hand in the first place.
usually a software project provides one or more text files containing the ddl statements to create the necessary tables. what tool you use to execute those statements doesn't really matter. some php projects alwo provide a installer wizard php file which can be executed directly in the browser, so you don't need any additional tools at all.
I'll try to only answer what your question is - "Is it preferred to create tables in mysql using a third party application (phpmyadmin, TOAD, etc...) instead of php?"...
Yes, it is preferred to create tables or alter them or delete them or perhaps do any DB-related activity that is outside the scope of what interfaces your application provides, in MySQL using any of the many available MySQL clients. And the reason is because these applications are designed to perform DB related tasks and are best at doing them.
Though you may as well use PHP for creating tables depending on the situations, like if the application uses dynamic tables or needs "temporary" tables for performing complex jobs or storing intermediary results/calculations. Or perhaps if the application provides interfaces to manage/control certain aspects, like assume that a certain application consists of various user-roles that have their respective columns in the table. If the application provides rights to the admin to delete or add new roles, which will need to delete or add new columns, it's best to do such queries from PHP.
So, putting it again, use MySQL for any DB work that is not related or affected by what functionality or interfaces your PHP code provides.
Sidenote: Though I've used phpMyAdmin, TOAD, WorkBench and a few others, I think nothing's as efficient and quick as the MySQL client itself, i.e. working directly on the MySQL prompt. If you've always used GUI clients, you might find it unattractive to work on the prompt initially but it's real fun and helps you keep syntaxes on your tips :-)
You question might have been misunderstood by some people.
Charles Sprayberry was saying there's no best practice as far as which 3rd party MySQL client (i.e. phpmyadmin, TOAD, etc.) to use to edit your database. It comes down to personal preference.
Abhay was saying (and I really think this was the answer to your question), that typically, your application does not do DDL (although exceptions exist). Rather, your application will usually be performing DML commands only.
DML is Data Manipulation Language. For example:
DDL is Data Definition Language. For example:
create table
alter table
drop table
Basic SQL statements: DDL and DML