Vb.net Programming

[alexander]

what about a poll... anyone up to make it, i'm about to hit the bunk :confused:

[Qfwfq]

Buffy, I hope you'll stumble across a guy that's right up your line but forced to spend his life in flight of his terrible old mah!!!!!! :girl_hug:

:hyper:

 

True: Edsgar would give up multiple inheritance to avoid those gotos!

He would have to also give up defining operators, templates, enumeration types and whatnot... Geezzzzz, he was a tad before the OO days too:

Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148. :confused:

[TheBigDog]

Here is the code for the Fractalator. The files can be opened in the .net development environment, or just in notepad. I have comments to explain how each peice works. It has many examples that I would have found handy when I was just learning this particular language.

 

Let me know if you have any questions. I may break this into peices for the nicer examples. I will probably start with control arrays which do not exist in vb.net but I use here very nicely. ;)

 

I found some things I would change when I was adding comments today. But I left it, warts and all, in hopes that my comments as to why it was not well done might be as helpful as everything being correct.

 

If you want to make changes or enhancements feel free. And show them to me so I can check them out!

 

Bill

[Pyrotex]

thanks well thats all well and good, because im using java - but what about some advantages of it, not just disadvantages of vb..

I now consider myself a wizard at VBA (the version that comes with professional grade Excel), and I can tell you, it ALSO causes hair loss, stuttering, erectile dysfunction, cooties and delusions of grandeur.

 

The big advantages of VBA(Excel) are as follows:

1. you do not have to learn and memorize 350 pages of defined classes, objects, object trees and their hierarchical relationships, attributes and processes.

2. you have an existing "sandbox" in which to prepare inputs and display your outputs. (the spreadsheets).

3. the Excel spreadsheet application already has your events, event listeners and interrupt handlers in place and working.

4. there are no extra INCLUDE files that you have to scrounge around for--everything you need is already in there.

5. you do not have to learn and memorize 425 more pages of defined classes, objects, object trees and their hierarchical relationships, attributes and processes.

 

Hmmm... that's about all. I have this "Excel Guide to Mastery" book that I have been writing for 8 years. I include only the stuff I really needed, and don't even mention the rest. The two chapters on VBA (elementary and advanced) only runs about 20 pages. Twenty!!

 

Try learning JAVA in 20 pages. HAH! It is to laugh in the very face!

[TheBigDog]

So, I am looking for a forum to ask a question about a vb.net issue, and what pops up 9th on Google? This thread at Hypography started by me!

 

Here is my problem...

 

I have a .csv file created by an Excel file. I used Access to create a linked table to the .csv file. The file contains orders that need promise dates, but I have to check the file so that I don't send duplicate records, and break it into three text files that I had to the promising engine.

 

Here is my problem, .net will not allow me to use a connection to the linked table. I can test the connection, and it works, but it gives me an error that it cannot find the table attributes when I try and use the data object for the linked table. I can connect to unlinked tables without any issue. Iss anyone familiar with this issue? Am I missing something? I have scoured the net with little luck.

 

Thanks

 

Bill

[Buffy]

You're using a lot of levels of indirection, which can get you in trouble. I use Access when I need to, and I only link to SQLServer, but programming against linked tables is problematic in my experience.

 

So, I'd propose simplifying: If you're really only looking up a single value on a single id, I'd just parse the csv file directly.

 

Alternative if you want to simplify your coding, import the file as a normal Access table.

 

If you want to continue doing it the way you are, its going to take much more information about the error message you're getting. Happy to look it up for you if you're not an MSDN member....

 

DB's'R'Us,

Buffy

[C1ay]

I have a .csv file created by an Excel file.

 

I assume that you have a valid Excel file, .xls, that you started with?

 

Open Excel and select Data>>Get External Data>>New Database Query. It will ask you to choose a data source. Select "Excel Files". Browse to your Excel file and select it. If it says there are no tables then select "Options" and make sure all the boxes are checked. You should then see a list of worksheets as tables. Select the worksheet you want to query and the > to move the columns to the right box. Hit "Cancel" and it should ask if you want to finish editting the query in Micro$oft Query, say "Yes". Now you can use the same interface as Access or SQL directly on your Excel worksheet. The simplest thing you could probably do at this point is double click the * in the table view, select View>>Query Properties and check the "Unique Values" checkbox and hit OK. That will add the "Distinct" keyword to the background SQL and filter your data to unique records. From the File menu your can return the data to excel and save it.

 

This is a simple way to use SQL against worksheets. You can even use joins between sheets just like they are tables without invoking Access. If you'd rather use Access then import the data and use it in Access instead of linking to it.

 

Otherwise I feel the same about MS Office programming as Quigley does about six shooters. Like Quigley said, "I said I didn't have much use for one, not that I don't know how to use it." :)

[TheBigDog]

Thanks Buff and C1. I appreciate the feedback. I have taken a different tack. I am expanding the VB macro in the excel sheet to do the work for me. I had been writing a program that watched for the .csv file to be created, and then worked with it from there. But instead I am just going to use the original app to get more of the work done at once.

 

I will still have an Access DB for keeping track of the orders that have been sent on. There will be multiple excel sheets doing this, so a central record is needed at that point. I am just slapping together a quick and dirty interface for a proof of concept. A real developer will build a robust interface later without any of this MS Office nonsense.

 

I am almost done now... Thanks again for the help. :)

 

Bill

[C1ay]

But instead I am just going to use the original app to get more of the work done at once.

 

The original app? Is the data coming from another backend db? You should be able to do the whole task in either Excel or Access without having to use both. If your external app needs to store data for future retrieval and/or queries I'd do the whole thing in Access. Can you connect to the original app via ODBC?

[TheBigDog]

This is the best I can do. I have very strict rules to follow, and layers of security to respect. This is the best I can do without getting budget approval for a developer to spend time on it. Nothing like a big business.

 

Bill