hi kenneth,
" I would suggest that you identify which people need to use VB software and dont migrate them in the first stage. In second stage, perhaps you can have a Win3K server with remote desktop client running on Linux to give access to the VB Software. We worked that succssfully in an office with 75+ users. "
i am interested in this. Can you shed more light on the implementation. If this can be done with VB is it possible to do the same with tally.
On Tuesday 01 Mar 2005 6:57 pm, santosh rao wrote:
hi kenneth,
" I would suggest that you identify which people need to use VB software and dont migrate them in the first stage. In second stage, perhaps you can have a Win3K server with remote desktop client running on Linux to give access to the VB Software. We worked that succssfully in an office with 75+ users. "
where is this quote from?
i am interested in this. Can you shed more light on the implementation. If this can be done with VB is it possible to do the same with tally.
whether it is VB or tally, migration can only be done in stages. First place, for tally there is no way to export data. The only way is to import the contents of all vouchers into a spreadsheet, massage the data and re enter it into the new application. This is an exercise in futility. The best way is to start the new year on a new accounting package and retain a machine running the older tally stuff for some time for purpose of reference and record. So only opening balances would have to be transferred (manually) from tally.
As for VB, again there is no way to just port the software to linux. But you can be practically certain that the software, being written in VB will be pretty crappy. The best solution is to rewrite the whole thing in a scripting language like python or ruby. You will find the code is about 1/10th of the original and far more efficient. If this software is using a database backend, it could be possible to export the data from access/sql server, massage it and put it into a postgresql database. Again an exercise in futility as most probably the database design would be crappy. Better to redesign the database in postgresql.
Hi,
You got the person wrong, I made that quote and not kenneth.
santosh rao wrote:
hi kenneth,
" I would suggest that you identify which people need to use VB software and dont migrate them in the first stage. In second stage, perhaps you can have a Win3K server with remote desktop client running on Linux to give access to the VB Software. We worked that succssfully in an office with 75+ users. "
i am interested in this. Can you shed more light on the implementation. If this can be done with VB is it possible to do the same with tally.
Actually the work on this was done by Amish Munshi for one of my clients as a demo. Later the client moved on to that platform for the entire office. Perhaps he has a how-to or checklist for this (Amish are you listening ?)
It is easy to do and many of the offices do this for tally even on windows. Two of my clients currently do it for tally (but windows clients) since running tally on LAN for large users is too painful for lan traffic and the work will never get done on time.
What you need to do set up a Win3K server and put the software on it. Then activate server terminal emulation software on the server. After that all network users using any windows client can log in to the server using a terminal emulation software. When they are connected, it will look as if they are actually sitting on the server and working. But if they log off (or minimise the terminal emulation window), they will get their own standard OS Desktop Screen.
In Linux, they already have a remote desktop / terminal emulation software. As far as I remember, the software is called rdesktop.
If you have any specific solution in mind, let me know and I will be happy to help.
Regards Saswata
-
Kenneth Gonsalves -
santosh rao -
Saswata Banerjee & Associates