Not necessarily an enterprise feature: I always forget that MS SQL Server does not allow aliases in the SELECT list to be reused further in the SELECT list, in WHERE, GROUP BY, something that I'm almost always using with SQL Anywhere. In MS SQL, you do have to repeat the expressions or use derived tables to be able to use aliases in different query clauses. Something like select Col1, Col1 + Col2 as Sum, SomeFunctionUsedOn(Col3) as MyCalcValue from MyTable where MyCalcValue > 100 order by Sum; I could name many more samples but one of the biggest topics is the help: In that respect SQL Anywhere seems waaaaay more informative, focussed and clear than the MS counterpart. answered 28 Apr '21, 05:33 Volker Barth Some more examples include
(29 Apr '21, 10:17)
Volker Barth
|
Easy to admin. We don't have a large IT unit.
Has everything we need and more. answered 29 Apr '21, 08:48 rsnyder |
I've been using SQL Anywhere since version 7. Our company has 100+ installs across the US (PB 2019 and SA 11 or 16). Our largest account has 100+ users and 60 sales reps that use a app with Mobilink. Anytime we can't figure out a bug, we get a copy of the customer's database and log file, fire it up on a developer's PC, using dbengXX.exe, and run through the PB debugger. Generally, it takes more time to download a copy of the DB from the customers server, than to find the bug. Installing SA 16, setting up a server (dbsrv16.exe) with a blank database, back up events, Mobilin, etc. takes less then 15 minutes. Using MS SQL takes 2 strokes and a heart attack to do the same things.
permanent link
This answer is marked "community wiki".
answered 29 Apr '21, 08:58 Tom Mangano |
Please note that Azure does have support for microseconds to 7 digits using DATETIME2. See https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime2-transact-sql?view=sql-server-ver15.
That over-cooked Microsoft article https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime2-transact-sql?view=sql-server-ver15 is a perfect example of why it's important to get things right in the first place :)
Of course SQL Anywhere isn't entirely in the clear on this subject: remember the proposal for a data type of Date_and_we_really_mean_it_this_time to deal with the problem of Dates storing DateTimes and so breaking comparisons! Fixed a long time ago though :)
Hm, I don't remember, was that BC?