Comments on: NebulaXChange : Excel to MV and beyond http://Nebula-RnD.com/blog/tech/2007/11/excel-to-mv1.html Welcome to the Nebula Sat, 17 May 2008 20:29:57 +0000 http://wordpress.org/?v=2.2.2 By: dthiot http://Nebula-RnD.com/blog/tech/2007/11/excel-to-mv1.html#comment-106 dthiot Wed, 05 Dec 2007 15:16:06 +0000 http://Nebula-RnD.com/blog/tech/2007/11/excel-to-mv1.html#comment-106 The web service solution/idea is a great one whether you use mv.NET or some other component in the connectivity of the web service to the mv database.  It allows for support of a large number of client processes with very few database connections and does not require special configurations or installations on the client side.  As we make mv "data" more readily available to the non mv world then we are beginning to expand the reach of the mv world. The web service solution/idea is a great one whether you use mv.NET or some other component in the connectivity of the web service to the mv database.  It allows for support of a large number of client processes with very few database connections and does not require special configurations or installations on the client side.  As we make mv "data" more readily available to the non mv world then we are beginning to expand the reach of the mv world.

]]> By: Tony Gravagno http://Nebula-RnD.com/blog/tech/2007/11/excel-to-mv1.html#comment-100 Tony Gravagno Sat, 10 Nov 2007 23:36:09 +0000 http://Nebula-RnD.com/blog/tech/2007/11/excel-to-mv1.html#comment-100 <p>VSTO will only help on the client. Some method is still required to get from the client to the server. I could go direct from Excel/VSTO into MV via a custom telnet component but then I would be responsible for coding/managing communications. This product focuses on Excel integration, I don't want to have to maintain communications code. As an application developer using mv.NET I can focus on the task at hand and I don't need to worry about the communications at all. From the end-user perspective, most client/server products in our industry only work on an intranet precisely because they use some communications component that relies on access to a local hostname or IP address. With web services and mv.NET, anything I write will work on the LAN or over the internet. For LAN-only usage, if I use VSTO with mv.NET, I would have to install mv.NET client-side libraries. That's another technical issue that I don't want to deal with.</p> <p>Given all of these considerations I think I've chosen the right combination of technologies.</p> VSTO will only help on the client. Some method is still required to get from the client to the server. I could go direct from Excel/VSTO into MV via a custom telnet component but then I would be responsible for coding/managing communications. This product focuses on Excel integration, I don’t want to have to maintain communications code. As an application developer using mv.NET I can focus on the task at hand and I don’t need to worry about the communications at all. From the end-user perspective, most client/server products in our industry only work on an intranet precisely because they use some communications component that relies on access to a local hostname or IP address. With web services and mv.NET, anything I write will work on the LAN or over the internet. For LAN-only usage, if I use VSTO with mv.NET, I would have to install mv.NET client-side libraries. That’s another technical issue that I don’t want to deal with.

Given all of these considerations I think I’ve chosen the right combination of technologies.

]]> By: jra http://Nebula-RnD.com/blog/tech/2007/11/excel-to-mv1.html#comment-99 jra Sat, 10 Nov 2007 22:34:21 +0000 http://Nebula-RnD.com/blog/tech/2007/11/excel-to-mv1.html#comment-99 Hi Tony:This is a good idea. I agree that for many reasons mv.NET is a good product to use with this product.What i do not have so clear is to use a web service. If we are talking about Excel (Word, PPT, Outlook, etc.) we are talking about an Office environment. I agree that VBA (even with XLA so the users do not need to do anything) is not an option. The product must be in the .NET framework. For that i thonk it will be better to use VSTO. Actually VSTO is the Office .NET devolopment product. Has you explore that way?joseba Hi Tony:This is a good idea. I agree that for many reasons mv.NET is a good product to use with this product.What i do not have so clear is to use a web service. If we are talking about Excel (Word, PPT, Outlook, etc.) we are talking about an Office environment. I agree that VBA (even with XLA so the users do not need to do anything) is not an option. The product must be in the .NET framework. For that i thonk it will be better to use VSTO. Actually VSTO is the Office .NET devolopment product. Has you explore that way?joseba

]]>