I'm trying to evaluate dart programming language. Right now I try to figure out if it is possible to access a Sybase Anywhere 12 DB using dart.
I've searched pub.dev (and google in general), but couldn't find anything.
So, does anyone know how to access Sybase Anywhere 12 from dart ?
thanks for any help!
I haven't used sybase for almost 15 years, but unless I'm mistaken or change on the part of sybase, it is the Transact SQL protocol which is used to query Sybase.
when I was programming at the time I often had to use the libraries for MS SQL Server.
So, if Transact SQL is still used you can use libraries for MS SQL Server like https://github.com/nippur72/SqlServerSocket for example.
But it is necessary to install a windows executable on the server
Another solution place an API between your Flutter application and the SYBASE server
This can easily be done in node.js for example since there are packages to connect to Sybase.
Related
I am using Influxdb with Grafana for a while and I like it.
I am confused with the new version of Influxdb2.0. I was searching the doc and could not find useful info.
I have some questions.
Will Influxdb be available only as bundled with db + ui as 1 single binary going forward? Can we have standalone DB?
Will the Flux replace the current SQL like InfluxQL ? Or InfluxQL will also be supported.
Yes, I believe the intention is to bundle the UI into the single binary so that it is always available with no additional installs. You can continue to use Grafana though - ignoring the bundled UI entirely*. There's no problem to ignore it so the DB is still "standalone". Since it is OSS, you could build a binary without the bundled UI if that is important for your use case.
InfluxDB 2.0 OSS is currently in RC0 (as of late Oct 2020). This version supports both InfluxQL via a compatibility API (/query) and Flux via the new /api/v2/query API querying. The query and response formats are different. The docs have examples. In general, Flux is the direction InfluxDB is going.
*There may be some rough edges in the RC around configuring the first user without using the UI and only using the API. I have not tried this. I would expect the API to continue to improve is this area.
I'm trying to work out how these two pieces of the jigsaw interact and fit together when connecting to an MS-SQL server on linux.
As I understand it, FreeTDS is protocol (i.e. a set of rules) for talking to MS-SQL and it is the thing that actually does the talking. Unixodbc is a driver that implements the ODBC API, i.e. implements a set of functions I guess.
Why are both things necessary? Can anyone elaborate on my sketchy understanding of what these two things actually do?
unixODBC is a 'DriverManager' for ODBC. You can use unixODBC when on a Linux or *nix system to connect to any ODBC-capable database. Doing so means that you can write one lot of database queries which you should be able to use between different databases. If you were not on Unix, you would use a different Driver Manager, for example the built-in MS Office one.
To make all the components clear: if you're using a language, let's say Python, to connect to SQL Server, your connection might pass from Python's pyodbc (translates python objects to and from unixODBC), to unixODBC (manages drivers, such as FreeTDS), to FreeTDS (translates unixODBC objects to and from the TDS protocol, which Microsoft embraces) to SQL Server.
The unixODBC website http://www.unixodbc.org/ says:
An ODBC application makes ODBC calls to the DriverManager. The DriverManager carries out a number of tasks for the application such as:
ensuring the proper driver is loaded/unloaded
validation tasks
3.5 to 3.0 to 2.0 call and data mapping
Most calls to the DriverManager get passed onto the loaded Driver to be further processed but that is of little concern to the application.
Some advantages to using an ODBC DriverManager include:
portable data access code
runtime binding to a Data Source
ability to easily change the Data Source
Briefly, it is the Driver Manager which reads your DSN, looks at the configured data sources, and decides where and how to connect.
Depending on which database you use, you will need a different driver. This piece of code 'translates' your requests made using ODBC to the right protocol for the relevant database management system. This is the component that would need to be different for different data sources. In your case, TDS is the protocol used by MS SQL Server. FreeTDS is a free software implementation of this protocol.
See also Wikipedia https://en.wikipedia.org/wiki/Open_Database_Connectivity (emphasis kept):
ODBC accomplishes DBMS independence by using an ODBC driver as a translation layer between the application and the DBMS. The application uses ODBC functions through an ODBC driver manager with which it is linked, and the driver passes the query to the DBMS. An ODBC driver can be thought of as analogous to a printer driver or other driver, providing a standard set of functions for the application to use, and implementing DBMS-specific functionality. An application that can use ODBC is referred to as "ODBC-compliant". Any ODBC-compliant application can access any DBMS for which a driver is installed. Drivers exist for all major DBMSs, many other data sources like address book systems and Microsoft Excel, and even for text or CSV files.
FreeTDS is the implementation of the TDS protocol, it handles everything and is fully capable of operating without unixODBC.
ODBC is a wrapper around FreeTDS and provides a common API that is better documented than FreeTDS' internal API.
As FreeTDS.org/faq.html indicates:
FreeTDS offers three client libraries and one internal one (libtds). We generally encourage people to use one of the client libraries, and discourage writing to libtds, because the latter is evolving, more subject to change, less well documented, and harder to use.
Both pieces aren't necessary, it's just that some people prefer to use wrappers rather than learn a new API to do something similar to what they already know in a different API. As FreeTDS' FAQ indicates, they support other open APIs other than ODBC and their internal library is fully capable of handling the connection all on its own.
What options exist to query RMS files in OpenVMS? The context for the query/access would be for BI & reporting. Currently, a very old FOCUS (Infomation Builders, v. 6.9.8) is in use, and that only from within the native OpenVMS command line shell.
My challenge working within the VMS environment is that output is intended for off-platform consumption & analysis in Excel, R, and Business Objects/Crystal Reports, and Splunk/Hunk. On-platform, I'm limited in what I can use by whatever I can compile &/or run from within my own user space, and the CONNX & similar tools all look to require a server process in the VMS environment.
Edit: I have accepted a comprehensive answer which, given organizational constraints, may not be feasible. My likely path will be to write additional data extractions jobs in FOCUS, and incur the latency & maintenance overhead that goes along with that.
Do you want to the reporting to be on-platform, or off-platform (for example with Excel)?
On-platform, after 30+ years, I still really really like Datatrieve, as mentions in a comment.
This tool was created before SQL became all the rage, so its query language takes a little getting use. It knows show to used just about every RMS option (keys, RFA's for collections, joins, locks and sharing,...)
I'm sure there are multiple commercial tools like Focus you mention, and perhaps the IGH tool Vselect for data extraction, column shuffling, sorting. Some would even recommend OpenVMS native SORT but now you are still in Command Line space.
For a (green screen) windows approach, and command line, perhaps check out the freeware tool DIX: http://www.oooovms.dyndns.org/dix/
Off-platform google for "openVMS odbc" (jdbc). You'll find tools from Connx, Easysoft and "Connect" from the company I work for : Attunity.
Those will allow you to use (windows, linux) tools like DBvizualizer or Excell to get to the OpenVMS sourced data.
Perhaps an interesting hybrid could be Attunity's Connect ( "AIS" ) solution which allows for SQL language RMS file access, but on platform (NAV_UTIL) and off-platform, ("Studio, Nav_util, Oracle db-link, ODBC, JDBC, XML, ... )
For better help, please clearify the query still better. Notably the remark " only from within the native OpenVMS command line shell". What's wrong with that? :-). What alternative access did you envision? fake-gui, DECwindows? Native API? Remote API? ...
Hope this helps some already,
Hein
You could consider writing code in a native language such as C or Java. The company I work for uses Apache, DCL scripts in cgi-bin, and the Userbase 4GL to put an Intranet reporting front-end over an OpenVMS legacy system. As long as you wrap the output in HTML etc Apache will stream it back to a browser which will interpret it accordingly. However, with the impending move to Itanium we're faced with no support for porting Userbase. If anyone knows who holds the source code could they tag a reply onto the end of this. We're looking for a terminal (character mode) reporting solution for Itanium as not all users have PCs. If it weren't for this we'd just slap Crystal over CONNX and call it a day. Many thanks.
Further to my previous answer I'm now evaluating R as a reporting solution, using the RODBC to interrogate the RMS database via CONNX using R's RODBC library.
Just wondering what the best way to access read only information form a Microsoft Access file in a Rails 3 application would be, I know I could convert the data to CSV and then do a manual import into Postgres or SQLite but this data is ever changing as it is used in a business application at my work place and this would mean doing an import a few times a day.
If anyone could point me to a solution then it would be much appreciated.
There are commercial cross-platform odbc drivers for MS-Access I think, but nothing open-source that can reliably read/write (and I could have used them once or twice in the last few years).
If you are on Windows you should presumably be able to use ODBC with a .MDB compatible driver. If not, you might be able to use MS-SQL server as a proxy (there's the "express" free version) or perhaps a java/perl proxy (jackess / DBD::Proxy) but none of these are going to be a simple plug+play solution.
If you're committed to Access then something like EasySoft's driver might be the simplest solution. Worth the money if it works well, but I've no direct experience with it myself.
Although this is an old question, I ran into this problem myself this week and managed to resolve access to an .mdb database from rails using the mdb gem as per:
https://github.com/jkotchoff/heroku_rails_microsoft_access_mdb_example
I have Delphi Professional 2007 and 2009 and was thinking of upgrading either or both to Enterprise due to a new project that requires me to interface to a Sybase ASE database.
I did some research and it appears that 2007 Sybase driver leaked memory and it doesn't appear that this problem was fixed.
Does anyone know if the Codegear Enterprise drivers for Sybase ASE are reliable and do any alternatives exist?
The BDE had some huge shortcomings and it seems that a lot of those were brought right into DBExpress. Some of these include:
No suport for multiple result sets
No way to get your hands on server messages that are not errors
No control over where the cursors are located
No support for async calls (where you use ct_poll)
My advice would be to write your own (simpler than it sounds) or to use ADO. ADO exposes a lot of ASE's functionality and the performance is very good.
Have you looked at NativeDB? The website might be a little off-putting, but I have a legacy D5 app that connects to ASA using their tools. At some point in the next month or two I'm going to have to buy an upgrade so that I have their latest D2007 driver, because I need to move that legacy app to D2007.
It works well (and it's damn fast) with ASA - I don't know about ASE but it might be worth a quick email asking them, or downloading a trial component. It's not that expensive for what it does, either.