Watcom International Corporation was a software company, which was founded in 1981 by Wes Graham and Ian McPhee. Founding staff (Fred Crigger, Jack Schueler and McPhee) were formerly members of Professor Graham's Computer Systems Group at the University of Waterloo, in Waterloo, Ontario, Canada. Watcom produced a variety of tools, including the well-known Watcom C/C++ compiler introduced in 1988.
Waterloo BASIC programming language was one of the earliest Watcom products and predates the existence of the company. During 1978 to 1979 Waterloo BASIC was developed targeting the IBM Series/1. In 1979 the system was ported to VM/CMS running on the IBM 370, 3030, and 4300 computers and an agreement was reached with IBM to market the compiler. Between 1980 and 1983 updated versions were released including ports to the MVS/TSO and VM/CMS. In addition to Waterloo BASIC some of the other early products included WATCOM APL, WATCOM GKS, WATCOM COBOL, WATCOM FORTRAN (WATFIV and WATFOR-77), WATCOM Pascal and the Waterloo 6809 Assembler. These were the basis and provided with the Commodore SuperPET [clarification needed].
In 1988, Watcom released their first C compiler for the IBM PC platform (and compatibles). It was released with a version number of 6 at a time when the latest version numbers of Borland's and Microsoft's C Compilers were version 5. These version numbers signified nothing and were used for marketing purposes. The compiler could create tighter and faster code than its competition.[1]
In 1992, Watcom began a move into the client-server arena with the introduction of Watcom SQL, a SQL database server product. Being a very small company (about 8 developers) they managed to produce high quality software, famous among software developers. Watcom SQL is still in production, now under the name SAP SQL Anywhere.
Watcom was acquired by Powersoft in 1994, and Powersoft merged with Sybase in 1995.[2] In May 2000, Sybase spun off their mobile and embedded computing division into its own company, Sybase iAnywhere (formerly iAnywhere Solutions Inc.). Sybase tried to re-target the Watcom compiler into a visual RAD tool, Optima++, but in 2003, because the product competed directly with the Sybase offering PowerBuilder, the product was discontinued. Its sister product, Optima-J, was continued. In 2003, the Watcom C/C++ and Fortran compilers were released as an open source project under a new name, Open Watcom.
A general question. I am developing for Sybase SQL Anywhere 10. For backwards comptibility reasons, almost all our Stored procedures are written in Transact-SQL.Are there any advantages or disadvantages to using T-SQL instead of the Watcom dialect?
The documentation for SQL Anywhere T-SQL compatibility is available online. There are some database options that change behaviour to more closely match what you would expect from Sybase ASE. In addition, there are some functions that can be used to translate from one syntax to another.
Note that if you want to start adding statements in the Watcom dialect into an existing stored procedure, you will need to change the SP so that it is entirely written in the Watcom dialect. You cannot mix syntaxes in a SP, trigger, or batch.
What KM said - on the other hand, the "Watcom" dialect is much closer to ISO/ANSI-standard SQL, so that dialect is more likely to match to some other products and to appeal to people familiar with SQL standards.
if you ever try to port to SQL Server (or you go for a job on SQL Server), Sybase T-SQL is very close to SQL Server T-SQL. Sybase and MS joined up back in the day, so the core of those languages are very similar.
Been an analyst using SQL Anywhere for a few years and just getting into database management. Regarding writing/developing procedures/functions, is there a particuliar programming language that is used or patterned after?
The original dialect was introduced into the product in 1992 and is called WATCOM SQL. The name is derived from the name of the company "WATCOM" and name of the product at that time. See for more information about Watcom the company. In its early years, WATCOM was known for its compiler technology and in particular its WATFOR Fortran compiler which was used by Universities around the world. As such, I would presume that the experience learned creating these compilers had some effect on the design of this dialect.
@Mark: Am I right to notice some kind of bias in favour of the first dialect in your description? If so, I would fully agree:) - And I am sure Watcom SQL seems much more familiar to those with experience in common programming languages...
@Mark: Hmm, you can bet the curiosity isn't really satisfied, I was looking for names... - I guess us users here do not only share a admiration for you SQL heroes, there's place for compiler gurus, too:)
@Volker: I am a little reluctant to name others without their permission. I will say that I know of at least six staff that worked on the Watcom compilers/interpreters and (trying not to give away too much info) some of them are users on this forum. I'll leave it as an exercise to the reader to figure out who. Note: I am not one of them.
@Mark: I fully appreciate your point of view, as it really would be unfair to tell about other persons's CV. (And yes, as a typical German citizen, I do care much about privacy - cf. the German Google StreetView debate...) - Besides that, I do have some suspicions:)
I've discovered you can't mix these two constructions in the same stored procedure (no matter how many lines apart they are) ...select as VariableName1... and ...select VariableName2 = ... (disclaimer: I only know up to version 10.0.1)
Forum problems?Maintenance logContact UsTerms of ServicePrivacy PolicyCopyright/Trademark InfoLegal
Powered by SQL Anywhere 17
Disclaimer: Opinions expressed here are those of the poster and do notnecessarily reflect the views of the company.
If '=' is replaced with 'default', the procedure gets created sucessfully. If a database, that was created with an earlier SQLA version, is rebuilt the procedure keeps working, but can't be modified without the noted change.
Btw, your comment to my other post regarding SQLDIALECT made me look at your sample again. In SC (12.0.1.4436) I can add that function using ISQL and then convert it to Watcom (changes syntax) and to TSQL (ditto). So it seems somewhat inbetween.
FWIW the parser seems to be [cough] flexible when dealing with so-called TSQL features; i.e., some of those features are freely available in Watcom-SQL scripts and they don't change the so-called "dialect".
Second - as you might imagine, TSQL compatibility is extraordinarily difficult since TSQL is a moving target. In particular the move by Microsoft to include statement delimiters (semicolons) in their TSQL dialect makes Microsoft TSQL much closer to SQL Anywhere's WATCOM dialect in terms of syntax, but moves it further away from ASE's version of TSQL.
Specifically, the CREATE PROCEDURE and CREATE FUNCTION statements in SQL Anywhere have never supported the combination of using IN, OUT, or INOUT with the TSQL default parameter assignment ('='). Transact-SQL has never supported the IN, OUT, INOUT declarations for procedure variables and still does not; see -us/sql/t-sql/statements/create-procedure-transact-sql?view=sql-server-2017.
However, if one omits the IN declaration for the parameter, as in the enhancement request here (Enhancement Request: in SP definition allow "=" instead of "default" for Watcom dialect (SA-17)) then the TSQL default assignment will work even though the procedure uses WATCOM syntax. The example used in that other post does work for me with current SA17 software and with 12.0.1.
Do you know if this is a 16 or 32 bit application? Getting 16 bit stuff
working on a 32 bit O/S is a bit tricky. You will need to learn all about
ODBC Thunking (assuming it's still supported)The 32bit stuff should just work since it hasn't changed that much. Given
the 32 bit ODBC stuff isn't setup correctly, and the age of the software I
suspect it is a 16 bit app.It may be easier to install a 16 bit O/S somewhere, add the application and
database and get your data out that way.
If you want details on our dalliance, read on. This post is intended to explain why I am a fan of SQL Anywhere, combined with the expectation that you may share some of my reasons and follow me in choosing it as the platform of choice for your ad-hoc databases or as the platform for your database applications.
April is a positioning 'guru', consultant, author, and keynote speaker. After more than 20 years in marketing in the tech world, and fueled by her many experiences of positioning product, she decided to fill the positioning knowledge gap.
- Find out why your best customers love what you do, and position your product in a way that isolates what they love most. In this story, they tried to sell a database that was an alternative to Excel but no one wanted that. What their customers loved was that it was packaged small enough to be able to use it on mobile devices. Repositioning: embeddable database for mobile devices.
- Find your competitive comparable. Don't make the mistake (as I did before) of thinking your competitor is another company that makes similar software. It might be, but it's likely that your real competitor is something more simple: the way your customer is solving the problem right now. If they are using an intern to do that annoying task, then you better be explaining why your product is better than chucking an intern at the problem.
- Finding your true competitive comparable means you can isolate your uniqueness. Your positioning can now include "Our customers value us because of X, Y, Z unique features that an intern does not have".
c01484d022