I'm in the process of working out a suitable interface between A-Shell and a CRM system. The CRM vendor has asked:

"Would it be possible to create an Alpha export that includes the current format (tables/fields) in a SQL output from Alpha?"

After I responded that there is some SQL support, the vendor wrote:

"I would love to learn more about the Alpha A-shell SQL option. Is there a conversion tool from the current version (flat file) to MS SQL?
Let me know what your research uncovers or a web-site I could visit."

I don't understand exactly what the vendor is looking for. Is there a way to output data from A-Shell to a SQL-importable format? Is there a website that the vendor can look at to find out what the A-Shell SQL interface can accomplish? Is there an A-Shell SQL document that I can read (apart from the postings in this BBS) to understand what would be involved in implementing these features?

As Frank might say, "Ahem...". Did this posting slip through the cracks?
-- SS --

Jack? Ty? Anyone? Helloooo...

Hi Steven,

The A-Shell/SQL interface is a direct interface for connecting to and working w/ databases. It currently supports MySQL directly and MySQL and SQLServer through ODBC.

Your question is a little broad, but there are 2 ways you could go about this.

1. Without A-Shell/SQL:
You can simply create a file which is importable yourself. We do this to update a website's database daily. We create a separate .csv file for each table, and then run the import program from cron at a time after the .csv files have been regenerated.

2. With A-Shell/SQL:
You can connect directly to the database and Insert/Update/Delete each record that you need to through the Databases SQL Query interface. Here you need to have network and user access to the database and the tables you need to keep updated.

Hope this helps a little

Hey Steve, perhaps if we both clear our throats, someone may hear... Ahem...??

Unfortunately im not in a position to give you any advise on this topic, but Stephen seems to be on the bleeding edge of this, perhaps you can give him a poke...

Just wanted to make sure the Steven sees that I did post about this just before Frank's post.

Sorry about the delay here. For some reason, the BBS is failing to notify me for posts just to this forum, and my usual method of linking directly to new posts from the notifications makes it too easy to overlook new posts.

That said, Stephen has pretty much provided as much of an answer as I could, without further information about what your vendor really wants. Although you or anyone is welcome to download the ASQL Reference , which is the only documentation currently available.

It is mostly a technical reference to the XCALL SQL calling parameters, although there are some introductory and other general remarks which might give some sense of what the initial goals were. But as it stands, it is purely a programmer's interface, so unless your vendor has their own A-Shell programmers (or is going to contract with you), I'm not sure how they would be able to get much out of it.

Another way to describe the general capabilities of ASQL are that it provides a programmer's interface capable of (and targeted at) real-time:

a) exporting data to new or existing MySQL databases

b) querying and importing data from existing MySQL databases

(As Stephen notes, you can use MySQL's import and export facilities to do similar things in a batch-mode using intermediate CSV files, command scripts, etc. So the primary appeal of ASQL is to be able to do it in real-time, completely under the control of your application logic.)

You could theoretically use the interface to convert or recode your application to use MySQL as the native data repository, rather than the ISAM or flat files you are using now. However, that would be more of a bleeding edge kind of project at the moment, since it would almost certainly require some significant design changes to your application, and I don't know of anyone who has actually done it (although some are thinking about or actually working in that direction).

I should also note that in addition to a native MySQL connector, we have an ODBC connector (theoretically allowing you to connect with any database offering an ODBC client). But ODBC is mainly convenient in the Windows world. (Linux ODBC drivers exist, but they add another level of complexity and cost, and thus would be less than ideal for your first ASQL project.)

Feel free to call me if you want to discuss it in more depth.

Thank you everyone. That should be enough to get me started. With a better understanding now of what ASQL can do, I am certain that the vendor's request was vague and needs clarification. I already produce CSV files that could be modified for their use, so perhaps they want direct SQL updating from within my programs. That could be an interesting project...

We have several customers updating their SQL Server from Madics data over night, they are all still using DVerto what we wrote along with DART but as DVerto can run separate of DART some just use this (and not DART) to transfer/copy their data directly from Madics/AShell to their SQL Server no matter their AShell platform Windows/AIX/Linux and most run this over night and do their own reports in other applications or link it with some external data they already have in a SQL database.

We only had a few requests so far of real-time updates but right now the development time/costs are putting them a little off and as most of the SQL data is used for reporting they are happy for it to be slightly out of date, or they run it manually during the day for a certain file.

Once we have a little more of a demand for real-time Ashell/Madics to SQL I can revisit the Ashell/SQL (what worked great under my Windows test a while back, so nice job Jack) never got to try it with the more complex mix of Linux ODBC to SQL or AIX! - I think that fun can wait another day..

More info on DVerto and i think a few examples can be found here at an older forum post.