|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Building a single EXE file in VB 2005?Oracle database, in order to extend a larger product that is developed by our colleagues in Germany (who use C++ and Java). As each app is small and simple, we have been distributing each to the customer in the form of a single EXE file. I have been attempting to build another one of these small custom apps, using VB 2005 Express Edition. It doesn't seem to be possible to produce a single EXE file using this environment: for a start, there is no File -> Make executable menu, only a more complex Build -> Publish menu, which I think produces an MSI installer file. There are deeper problems, however. Is there anything incorrect in my thinking below? 1) In order to write a program that takes the results of queries on an Oracle database and places them in an Excel spreadsheet, in VB6, we can use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the data in a single (fairly quick) step. The database facilities in VB.NET provide no equivalent: we must instead write (slow and possibly buggy) code that copies one row at a time from the query result into the spreadsheet (see <http://support.microsoft.com/?scid=kb;en-us;306022&spid=1249&sid=global>), or use (COM) ADODB. 2) If our code uses COM objects (eg ADODB in the above case), it isn't possible to compile the app into a single EXE file. It seems that VB.NET needs to create an Interop.ADODB.dll file in this case. I think if we want to continue to distribute single EXE files, it may be best for us to stick with VB6. Have I missed something? Ashley. Hello ashley,
First, if you can't work the bugs out of a simple double loop perhaps you should consider a different career path. Second, the Express versions of the IDE are not for commercial use. Third: Set ExcelRowCounter Set ExcelColumnCounter Loop over each row Loop over each column Write Value to Excel Cell Increment ExcelCellCounter Next Increment ExcelRowCounter Next -Boo Show quoteHide quote > We have been using VB6 to develop small custom apps that access an > Oracle database, in order to extend a larger product that is developed > by our colleagues in Germany (who use C++ and Java). > > As each app is small and simple, we have been distributing each to the > customer in the form of a single EXE file. > > I have been attempting to build another one of these small custom > apps, using VB 2005 Express Edition. It doesn't seem to be possible > to produce a single EXE file using this environment: for a start, > there is no File -> Make executable menu, only a more complex Build -> > Publish menu, which I think produces an MSI installer file. There are > deeper problems, however. Is there anything incorrect in my thinking > below? > > 1) In order to write a program that takes the results of queries on an > Oracle database and places them in an Excel spreadsheet, in VB6, we > can > use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the > data in a single (fairly quick) step. The database facilities in > VB.NET provide no equivalent: we must instead write (slow and possibly > buggy) code that copies one row at a time from the query result into > the spreadsheet (see > <http://support.microsoft.com/?scid=kb;en-us;306022&spid=1249&sid=glob > al>), > or use (COM) ADODB. > 2) If our code uses COM objects (eg ADODB in the above case), it isn't > possible to compile the app into a single EXE file. It seems that > VB.NET needs to create an Interop.ADODB.dll file in this case. > > I think if we want to continue to distribute single EXE files, it may > be best for us to stick with VB6. > > Have I missed something? > > Ashley. > Hello Boo...
Thanks for the reply. I don't see the need for your confrontational tone -- although I realise that I didn't give any information about my background, which hasn't helped. I did give a little detail recently in another post here: <http://groups.google.co.uk/group/microsoft.public.dotnet.languages.vb/browse_frm/thread/3f0bd46d9cf7ee1d?hl=en>. I would prefer to avoid writing code to do this particular job in order to minimise risk of bugs. I'm worried about typing issues, for instance. If a well-tested library already exists to do this (which it does in VB6), I'd prefer to use that. I will check out the licensing limitations on the Express editions -- thank you. There were other issues in my original posting. Does anyone have any more feedback? Ashley. Ashley,
I think that most of us are not aware of a more suitable standard library for your purpose in VB6. Interop with Office has never been a simple job, all was it alone that the development part of Office has showed in past in a way its own standards of programming to the world. But it is as well not so impossible to do as you show. There is a special Office Net addition in Visual Studio which is standard in more expensive versions. See in this link what is included in the Express version. http://msdn2.microsoft.com/en-us/library/b4z62wxz.aspx However in this sample set is as well a sample how to automate office, I have the idea that it will go in the Express version as well, because it are older samples. (I don't guarantee that). http://www.microsoft.com/downloads/details.aspx?FamilyId=08E3D5F8-033D-420B-A3B1-3074505C03F3&displaylang=en I hope this helps, Cor <ashley.w***@gmail.com> schreef in bericht Show quoteHide quote news:1151401545.460368.172830@c74g2000cwc.googlegroups.com... > Hello Boo... > > Thanks for the reply. I don't see the need for your confrontational > tone -- although I realise that I didn't give any information about my > background, which hasn't helped. I did give a little detail recently > in another post here: > <http://groups.google.co.uk/group/microsoft.public.dotnet.languages.vb/browse_frm/thread/3f0bd46d9cf7ee1d?hl=en>. > > I would prefer to avoid writing code to do this particular job in order > to minimise risk of bugs. I'm worried about typing issues, for > instance. If a well-tested library already exists to do this (which it > does in VB6), I'd prefer to use that. > > I will check out the licensing limitations on the Express editions -- > thank you. > > There were other issues in my original posting. Does anyone have any > more feedback? > > Ashley. > "GhostInAK" <ghosti***@gmail.com> wrote in message Not sure where you got that idea. From the FAQ for the express editions:news:be1391bfbde78c8672487163a5e@news.microsoft.com... > Second, the Express versions of the IDE are not for commercial use. "4. Can I use Express Editions for commercial use? Yes, there are no licensing restrictions for applications built using the Express Editions" Link: http://msdn.microsoft.com/vstudio/express/support/faq/#general /claes "Claes Bergefall" <louplou@nospam.nospam> wrote in message He probably meant "not for commercial use" as in XP Home is not (intended) for news:Ou1I%23EgmGHA.3980@TK2MSFTNGP02.phx.gbl... > "GhostInAK" <ghosti***@gmail.com> wrote in message > news:be1391bfbde78c8672487163a5e@news.microsoft.com... >> Second, the Express versions of the IDE are not for commercial use. > > Not sure where you got that idea. From the FAQ for the express editions: > > "4. Can I use Express Editions for commercial use? > Yes, there are no licensing restrictions for applications built using the > Express Editions" > > Link: http://msdn.microsoft.com/vstudio/express/support/faq/#general commercial use, XP Pro is. Ashley,
I make no bones about it.......in comparing VB.Net to Visual Basic 6, I think VB.Net is a huge step backwards. It made the easy stuff easier and the hard stuff harder. Not a great accomplishment if you ask me. VB.Net was written for Microsoft - not for developers. It solves internal problems for MS while creating problems for developers. It is the single, largest screw-up in the history of programming languages. You are not going to have a "small and simple" application using VB.Net. It will not be small because you cannot depend on the end user having .Net 2.0 installed. That will add 25 MB to your installation. This significantly increases bandwidth and distribution costs for you. (Don't even ask me why MS can make BETA WGA - Windows Genuine Advantage - a critical security download and not include the .Net runtime as a critical OS update...seeing as how .Net is their strategy for the future.) There is a way to make the installation simple and save some space while including only the portions of .Net that your application needs. It is called Thinstall. Thinstall can wrap your entire project (including all needed portions of the ..Net framework) into a single, encrypted executable. Your customer does not even need the .Net framework installed to use your Thinstall-wrapped app. It has built-in licensing with the ability to distribute time-limited trials of your software. It is a fantastic application for making no-install", but Thinstall starts at $4,000 per application - so it will increase your distribution costs. There are similar (and much less expensive) applications that wrap VB6 applications into a single exe - just so you know. As for what you are looking to do in .Net, I don't know if this will help - but take a look at http://www.xtremevbtalk.com/archive/index.php/t-239550.html. There is a discussion of similar functionality there. And, although we all know that VB6 was not perfect, VB.Net has more than its share of problems. If you haven't already, subscribe to the free KB emails at www.kbalertz.com. You can specify .Net 2.0 to limit the number of alerts that you get and you can also search for all of the kb articles for .Net 2.0 right on the site. IMHO, if what you have works, there is no reason to change to VB.Net. Don't complicate something that is working. You won't gain any speed advantage. Your distribution costs will increase. And, Microsoft is changing the framework yet again with WinFX - now known as .Net 3.0 - and depending on you to distribute it. Jim Hubbard <ashley.w***@gmail.com> wrote in message Show quoteHide quote news:1151321366.708459.162500@p79g2000cwp.googlegroups.com... > We have been using VB6 to develop small custom apps that access an > Oracle database, in order to extend a larger product that is developed > by our colleagues in Germany (who use C++ and Java). > > As each app is small and simple, we have been distributing each to the > customer in the form of a single EXE file. > > I have been attempting to build another one of these small custom apps, > using VB 2005 Express Edition. It doesn't seem to be possible to > produce a single EXE file using this environment: for a start, there is > no File -> Make executable menu, only a more complex Build -> Publish > menu, which I think produces an MSI installer file. There are deeper > problems, however. Is there anything incorrect in my thinking below? > > 1) In order to write a program that takes the results of queries on an > Oracle database and places them in an Excel spreadsheet, in VB6, we can > use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the > data in a single (fairly quick) step. The database facilities in > VB.NET provide no equivalent: we must instead write (slow and possibly > buggy) code that copies one row at a time from the query result into > the spreadsheet (see > <http://support.microsoft.com/?scid=kb;en-us;306022&spid=1249&sid=global>), > or use (COM) ADODB. > > 2) If our code uses COM objects (eg ADODB in the above case), it isn't > possible to compile the app into a single EXE file. It seems that > VB.NET needs to create an Interop.ADODB.dll file in this case. > > I think if we want to continue to distribute single EXE files, it may > be best for us to stick with VB6. > > Have I missed something? > > Ashley. > Hi Ashley,
I ran into the same Excel issue using adClipString with VB6. It was so easy passing a recordset to Excel as a display interface for SQL queries. The work around I came up with for VB.Net was to issue a SQL query, parse all field headings with VbTab, and then parse the returned fields for each row. The output is wrtten to a file, for which I then call Excel to display. (It was only a couple of lines of code. See below) Also, I've read that you can call old ADO recordset code from VB.Net by setting a certain type of reference, so that you could use your current code under VB.Net. I just haven't tried it yet, because of the easy workaround listed below. Something like: sData = "" strSQL = "select * from DBA_HIST_LibraryCache" Get_Field_Values() 'oWrite = oFile.AppendText("C:\OracleAwrData.xls") oWrite = oFile.("C:\OracleAwrData.xls") oWrite.WriteLine(sData) oWrite.Close() Shell("C:\\Program Files\\Microsoft Office\\OFFICE11\\Excel.exe " & _ Chr(34) & "C:\OracleAwrData.xls" & Chr(34), vbMaximizedFocus) Private Sub Get_Field_Values() selectedDatabase = cmbServers.Items.Item(itemCountPointer) Dim cnDBMS As New OleDbConnection cnDBMS.ConnectionString = "Provider=msdaora;Data Source=" & selectedDatabase & ";User Id=" & txtUserID.Text & ";Password=" & txtPassword.Text & ";" cnDBMS.Open() Dim cmDBMS As New OleDbCommand(strSQL, cnDBMS) Dim rdrDBMS As OleDbDataReader rdrDBMS = cmDBMS.ExecuteReader(CommandBehavior.CloseConnection) iFieldCount = rdrDBMS.FieldCount sHeadingFlag = "N" Do While rdrDBMS.Read() If sHeadingFlag = "N" Then sHeadingFlag = "Y" For I = 0 To iFieldCount - 1 sData = sData & rdrDBMS.GetName(I) & vbTab Next sData = sData & vbCr End If For I = 0 To iFieldCount - 1 'sData = sData & selectedDatabase & vbTab & CStr(Date.Now.ToShortDateString) & vbTab & CStr(Date.Now.ToShortTimeString) & vbTab sData = sData & CType(rdrDBMS.GetValue(I), String) & vbTab Next sData = sData & vbCr Loop cnDBMS.Close() End Sub -- Show quoteHide quoteJoseph Karpinski "ashley.w***@gmail.com" wrote: > We have been using VB6 to develop small custom apps that access an > Oracle database, in order to extend a larger product that is developed > by our colleagues in Germany (who use C++ and Java). > > As each app is small and simple, we have been distributing each to the > customer in the form of a single EXE file. > > I have been attempting to build another one of these small custom apps, > using VB 2005 Express Edition. It doesn't seem to be possible to > produce a single EXE file using this environment: for a start, there is > no File -> Make executable menu, only a more complex Build -> Publish > menu, which I think produces an MSI installer file. There are deeper > problems, however. Is there anything incorrect in my thinking below? > > 1) In order to write a program that takes the results of queries on an > Oracle database and places them in an Excel spreadsheet, in VB6, we can > use (COM) ADODB and Excel.Range.CopyFromRecordset, which copies the > data in a single (fairly quick) step. The database facilities in > VB.NET provide no equivalent: we must instead write (slow and possibly > buggy) code that copies one row at a time from the query result into > the spreadsheet (see > <http://support.microsoft.com/?scid=kb;en-us;306022&spid=1249&sid=global>), > or use (COM) ADODB. > > 2) If our code uses COM objects (eg ADODB in the above case), it isn't > possible to compile the app into a single EXE file. It seems that > VB.NET needs to create an Interop.ADODB.dll file in this case. > > I think if we want to continue to distribute single EXE files, it may > be best for us to stick with VB6. > > Have I missed something? > > Ashley. > >
What errors are not trappable?
Resolution in VB.NET Lost with creating a db connection... help!? Using an object from a Generically defined class as a variable. Very strange string problem using ASCIIEncoding passing values to html document from .Net app Is it possible to order a Visual Basic 2005 Express CD from Microsoft? Dynamically Creating A CSS Class Merging workbooks Microsoft Access Tab Controls |
|||||||||||||||||||||||