Prev: TCP/IP Session example connecting to Asterisk Gateway
Next: Performance over network
From: johan.nel on 1 Dec 2008 00:24
Hi Al,

> the rest of us ), if you could write up a slightly more detailed case

I have planned to rewrite one of my apps from scratch over December,
however as Karl also asked for a "Moving DBF to SQL for dummies" I
will try and slot some time in in coming week to get an article(s)
going.

Regards,

Johan
From: Ginny Caughey on 1 Dec 2008 06:57
Thanks, Johan. It sounds like you've got some great .NET apps now! I'm
curious why you translated the C# code to Vulcan though. You know you could
just use them from Vulcan.

--

Ginny Caughey
www.wasteworks.com



<johan.nel(a)xsinet.co.za> wrote in message
news:0f851572-38dc-4d26-a836-f98ceed8d1c1(a)h5g2000yqh.googlegroups.com...
> Sorry, seems something went wrong with my posting, lets try again...
> Hi Ginny,
>
>> As an aside, you mentioned in another post that moving VO code to Vulcan
>> is
>> easy. Have you actually done it? I was under the impression that you
>> didn't
>> have any large VO apps in production. I think it would be an even
>> stronger
>> argument if those of you (and I know you're out there!) who HAVE moved a
>> big
>> production VO app to Vulcan would share your experiences on this
>> newsgroup.
>
> Well since you asked here is my experience and route that I followed:
>
> 1. A data-driven environment, primarily aimed at DBF and using the
> internal SqlClasses of VO (2.6) supporting 23 applications with a bit
> of bBrowser, FabPaint and Graphics4VO as 3rd party libraries.
> 2. I converted straight from 2.6 to Vulcan without the help of the
> transporter as my reasoning was that the transporter would "force" me
> to think inside the box and VO windows etc.
> 3. I used native .NET classes for all my conversions.
> 4. I dropped the DBF and redesigned all classes to work with SQL
> (using PostgreSQL and the Npgsql.dll assembly). Also stayed as close
> as possible to ANSI SQL except where a Postgre feature would
> streamline statements enabling less client/server interaction in
> getting the job done.
> 5. Obviously the conversion to SQL allowed me to create triggers to do
> some of the work that would otherwise be done by the application in a
> DBF environment.
>
> I am 3 months down the line and can say with confidence that I have 23
> stable applications running in .NET with Vulcan.
>
> Obviously there are still a couple of "nice to have"'s that I still
> need to attend to like:
> 1. A generic query builder that can filter data pre-loading it into
> DataSets/DataTables/BindingSources.
> 2. A generic query builder that can filter records in DataTables and
> DataSets this would basically be a subset of the query builder
> mentioned in point 1.
> 3. Converting my G4VO wrapper to work with ZedGraph, but this is not
> that big an issue, its just to make sure I am passing the data in the
> correct format into ZedGraph and the correct property setting matching
> to be done.
> 4. I am still investigating a good report class as substitute for
> RP2.14, but in the meantime I am using a wrapper around the
> PrintDocument class with reasonably good results. fyiReporting seems
> promising as it allows charts to be part of the report. Something I
> previously stayed away from.
>
> In conclusion, three months down the line, probably another month and
> I will put VO on the shelf next to my Clipper, dBase and Pascal
> boxes... <VBG>
>
> I can definitely say from my perspective that YES you can port
> applications with ease into Vulcan even without the transporter and
> waiting for 3rd party libraries to become available, just do a bit of
> researching on the internet for .NET examples... csharp-source.net
> and csharphelp.com provided me with 90%+ of what I needed to convert.
>
> Just my 2cents worth.
>
> Regards,
>
> Johan Nel
> Pretoria, South Africa.

From: Al Acker on 1 Dec 2008 17:20
Thanks much!!!

Al

Editor, #using Vulcan.NET

You can download the latest Issue via http://goVulcan.NET or
http://usingVulcan.NET



<johan.nel(a)xsinet.co.za> wrote in message
news:81344c3a-8057-48e0-b3d9-fec0289abde1(a)13g2000yql.googlegroups.com...
> Hi Al,
>
>> the rest of us ), if you could write up a slightly more detailed case
>
> I have planned to rewrite one of my apps from scratch over December,
> however as Karl also asked for a "Moving DBF to SQL for dummies" I
> will try and slot some time in in coming week to get an article(s)
> going.
>
> Regards,
>
> Johan


From: johan.nel on 2 Dec 2008 01:55
Hi Ginny,

> Thanks, Johan. It sounds like you've got some great .NET apps now!
> I'm curious why you translated the C# code to Vulcan though. You
> know you could just use them from Vulcan.

Sorry maybe my message was a bit misleading. It was in converting VO
code to Vulcan. I just used the c# websites to get an idea of the
syntax of some of the things I needed to do in the VO conversion to
Vulcan. More to see how one do it with the .NET class. I agree why
convert if you can just use it directly. Except maybe if it is for
learning how to do it in Vulcan...

Regards,

Johan
From: Ginny Caughey on 2 Dec 2008 07:36
Johan,

Thanks for the clarification, and congratulations!

--

Ginny Caughey
www.wasteworks.com



<johan.nel(a)xsinet.co.za> wrote in message
news:58d6f9ee-c2c4-4385-a929-16839a97e7d8(a)t11g2000yqg.googlegroups.com...
> Hi Ginny,
>
>> Thanks, Johan. It sounds like you've got some great .NET apps now!
>> I'm curious why you translated the C# code to Vulcan though. You
>> know you could just use them from Vulcan.
>
> Sorry maybe my message was a bit misleading. It was in converting VO
> code to Vulcan. I just used the c# websites to get an idea of the
> syntax of some of the things I needed to do in the VO conversion to
> Vulcan. More to see how one do it with the .NET class. I agree why
> convert if you can just use it directly. Except maybe if it is for
> learning how to do it in Vulcan...
>
> Regards,
>
> Johan

First  |  Prev  | 
Pages: 1 2
Prev: TCP/IP Session example connecting to Asterisk Gateway
Next: Performance over network