to dll or not to dll - that is the newbie question 2

[ISPrincess]

I am having a MAJOR mental block with regard to writing classes and dlls. If I could get thru just one program with regard to this, I think I will be alright.

I have an existing VB exe that runs as a scheduled task every Sunday nite.

I have now found myself in the predicament of having to allow users on my ASP pages to either use the data generated on the above mentioned Sunday date or to trigger the vb app to generate new data. I would like to incorporate this same concept in other asp areas as well (for later data mining issues).

This program can take quite a while to run (20 min to 1 hr) as it gathers all inventory data from SQL and Unisys Mainframe systems. It can run on the server.

I need advise / help on 2 things.

1. How to rewrite this exe (if necessary) into com or dll or active x exe or whatever.

2. How to trigger it effectively from asp (I can email them that it is complete later)

Following is an overview of what my current VB App is doing.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First, upon load, it begins execution in sub Main()

Sub Main then calls a sub called loadparams() which basically reads an ini file and stuffs some public vars. I wont need this loadparams if I can pass a couple strings into the new app.

Then it call a sub called RFMFDelete() which just calls a SQL Stored Proc to delete all the data in a SQL 7.0 table based on the above mentioned params or a passed string.

Next, it calls another sub RFMFLoad() which gathers data from another SQL table into a recordset, then walks thru this recordset and gathers data from the mainframe using Unisys.DNSII clearpath driver, after which it takes all of that and inserts a record into a different SQL table.

When it is completely done, it then inserts a record into another SQL table wich triggers our company-wide VB app that will send an email to the requesting user. "your job is done".
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To those of you who are well-versed on object orientated architecture, this may seem like a joke, but I cannot get thru this in my mind. I have looked at other developers code and I understand what they are doing but cannot seem to tackle it myself.

Please help if you can.

Thank you! [Sunshine]

 

[JOLESEN]

Since your program takes a very long time to complete, I wouldn't allow it to run on demand.
I guess you couldn't make it fast enough (seconds) to be an online thing even if you wrote the program in C/C++ ?

Why not simply publish the content on the WEB-Server via an ASP-script doing some SQL-queries, and refresh the data on a daily / weekly basis using your already made VB-exe ?
/JOlesen

 

[ISPrincess]

I does run auto every Sunday and the content is published. But there will be times that they want to run it themselves at different times. ie: During Physical Inventory.

Not only do I not want to always have to run it for them - I feel it is inappropriate to have to call a programmer to 'refresh data'. Plus I have other items I would like to give them the option to 'refresh the data'.

 

[jfrost10]

Hey Hindes,

k, here is my take on your situation:

1. Kudos for realizing that a DLL might be a solution to your coding needs. The theory that I use when developing my apps is that the actual business logic/application logic should be seperated from the interface logic. that way, you can make applications that are interface independant (i.e. a vb app can use it, as well as a web app, etc.). There is no reason that your application couldn't be put into a dll. The flow would look something like this:

- we have a vb app with a "generate inventory" button and a label called lblSuccess. On the button click event it does:

Private Sub cmdButton_Click()
Dim objGenerate as new Generator

If objGenerate.BeginGeneration Then
lblSuccess = "Generation complete"
Else
lblSuccess = "Generation failed"
End If
End Sub

Now back in teh dll, we have a class called Generator. This has subs:

Public Function BeginGeneration() as Boolean
Private Function RFMFDelete() as Boolean
Private Function RFMFLoad() as Boolean

the LoadParams wouldn't be necessary assuming you could just put the variables from teh INI file directly into your dll.

So the BeginGeneration function would first call the RFMFDelete() function. If everything went ok, it would return True, else False. If True, then RFMFLoad() would fire, otherwise it would stop there and simply return False (which is handled in the vb app).

RFMF would then do the same thing, and return true or false depending on if successful.

Now that covers the OO part of things, but lets look at the real bottleneck of the architecture:
It will always be slower to have native code go through recordsets than have a RDBMS like SQL Server do the dirty work.

So this poses some questions:
- is there anyway that you can avoid returning the result set to the code, and just having sql server and Unisys play nice and create the necessary records together?
- have you looked into any DTS (data transfer services) functionality that WOULD let sql server 7 talk to Unisys (hand in hand with the point above, but I use sqlserver 2000, and not sure of the limitations or functionality of sql server 7)
- is it possible to have the data in the db updated everytime a new record is entered (whether in unisys or in the sql server) so that you could incorporate a view that is always being updated, can be reported off of, and would take no time to generate since the actual "generation" is continuously being done?

Anyway, you get the idea: there may be ways of leveraging sql server's functionality to your benefit, while creating an interface-independant application.

Sorry about the length, and I hope this helped somewhat.


D'Arcy

 

[ISPrincess]

This helped quite alot, thank you for your time.

In answer to your questions:

1. The recordset does not have to be returned to ASP, in fact, I do not want it to be. Actually, I want to have the dll trigger the sending of an email to the requestor at which time they can use the reports ASP page to access the data that was just created.
2. Are you talking about something like OPEN TI? That was going to be my next phase, but being unsure of the technology, I wanted to have something in place in case crunch-time became an issue.
3. Yes, and a view of the generated data is a great idea, thanks!

Now I have a question. Say I press the button to genereate the data for this, my asp will then trigger this dll. but at this very instance I want to let the user know "Report is being generated, you will receive an email when the data refresh is completed." and then free them up to either exit this intranet site or look at other pages or whatever. Will this happen? or will my asp page just sit there processing until the dll has completed everything it needs to do(which can take up to an hr as I said).??

 

[ISPrincess]

PS

Hey Frost -

You sound like my old softball coach... (hey hindes) - I miss that - thanks!

 

[jfrost10]

np, glad I could help


1. Sorry, I wasn't being clear: what I meant was is there any way that sql server could just deal with the resultsets, leaving no processing on the code side. And yes, the dll definately could do the email part, although sql server *could* as well (I'm pretty sure, but not 100% on that).
2. Not familiar with Open TI (guessing its something used with Unisys?). I know in SQL 2000 they have DTS, which lets you specify what sort of datastore you're trying to access, and dynamically feeds teh data to sql server and vice versa (kind of like a COM wrapper for datastores). Not sure if sql server 7 has native functionality for that though.

Your question brings up some interesting issues actually, mainly to do with the reports taking so long to process:

ASP sessions have a timeout limit, which can be set but you wouldn't want it to be higher than 20 minutes (otherwise your resources would just get murdered). And if a session dies, the objects within that session get killed off as well, so if you had our generator object going, then the session dies, it would die as well.

However, the real question is: if an object starts a transaction on sql server, and the object dies midway through the transaction, does the transaction carry on?

Off the top of my head, I'm not sure, and I'm not at work today to test it out. But that might be good test to run on your machine: create the dll, run a report you know will take a while, set the session timeout to something like 2 minutes (a time you know will expire before the report is generated), then see if the records are still written to the db. If that works, then the answer to your question is:

Response.Redirect to another page. Have that page actually create the object and start the sequence. Then, on that page, just have a label that says, "Report generating, you will be notified". Keep in mind, this will also mean that you'll need sql server to send out the mail though, since your object will probably be destroyed.

Now, another option to all of this (and one that I've only read about, never done) is the idea of pooled objects: objects that are always there, but just used whenver code needs them. With this theory, you *could* create an object on the web server, hold it in memory, and keep it session-independant, meaning that it would run weather an active session was available or not, as long as it was triggered (you'd need some very strong error handling in the class in case something buggered up as well).

And finally, a third option is the possibility that sql server 7, if optomized properly, and direct access to the Unisys system is found, and teh server itself has the resources, can dramiatically increase reporting times by 1/2 to 1/4 time. If thats the case, and the reports will reliably generate within say 1/2 hour, then you could set your session to timeout at 1/2 hour, have no need to dynamically destroy the session, and life is good.

I'm afraid I've brought up more design considerations than answers for you.


Web apps are a totally different beast than desktop; however, I know that sql server is quite powerful, and I'm sure there must be some ways to convert the data from unisys directly to it efficiently and effectively. Just a matter of figuring that out.

D

 

[ISPrincess]

Please try and think of the asp page in this way. the asp page will TRIGGER the program to start. it does not need to wait around for anything. I do not want sessions handing around for 20 min or more - this was never a consideration. Again, I just want to start the process - I have ways of taking care of the emailing etc later.

So how can I TRIGGER a vb app and then move on?

 

[jfrost10]

GOT IT! (well, one possibility anyway):

you mentioned in your earlier post that you have records written to a table, which then emails the users. The same method would work here as well:

1. ASP page takes the user info (like email), creates the object, and triggers the delete and the Load, but the load simply writes a record to a table in the database (more than likely the email table you have set up
2. The ASP page then directs the user to the "you will be emailed when the process is completed" and the web interaction part is done.
3. Back on the SQL Server, a trigger is activated when the email was written to our table, and the processing of the data begins.
4. The processing completes, a stored proc grabs the email from the table, and sends the notice to the user

That way you don't have to worry about the session issues with the web side of things.

One thing also to keep in mind: a vb DLL is NOT an application: it is a collection of business logic arranged into classes. A VB Application is simply the interface to that logic, as is a web application with asp.

Now there may need to be some variations to this:
i.e. How many records are we talking about coming in from teh Unisys table? You more than likely would get better results if you could take the data and save it into temp tables into sql server. That way, sql server can do all the main dataprocessing, all in its own format, and there's less overhead on the code. This assumes though that:
a) the amount of records being brought back and saved to the sql server doesn't hamper performance in any significant way
b) that the unisys data can be converted comfortably to sql server variable types (although since you were going through it before and adding it to sql server, I don't think this shoudl be an issue).

However, this means that now your actual process logic is within sql server. Is that bad? no, especially since for heavy processing of potentially thousands of records, sql server will hands-down beat a vb application in speed and efficiency every time. It does mean a different focus to your architecture from the vb coding side to teh t-sql side of things.

D

 

[ISPrincess]

Wow! Alot of really great things to think about! Thank you very much.

And thanks for the clarification of the definition of a dll - sometimes it's just that small change in thinking that can help get me over the learning curve.

I sincerely appreciate all your time - frost.

Still not sure I can do alot of the processing on the sql side with regard to the Unisys data. May need to still trigger VB. Could be I need to have a timer in a vb app somewhere then this asp page can create a file or some record in a table that flags the vb app to start processing.

I think what I am looking for is called 'asynchronous processing' and I guess that is not going to happen in vb. I hear it will be / is in vb.net but we are not using that yet.

Again, I appreciate all your thoughts - they have helped enormously!

 

[jfrost10]

np, glad I could help


I was developing in vb6.0 for a year before getting my current gig where we're doing .NET development, and believe me: its DEFINATELY worth the switch! Hopefully your company brings it in soon for you.

When you get it figured out, drop a post back here and let me know how it worked out for you.

D

 

[Polu]

Hello all!

I know that it's a bit late to help you, but here are any ideas about how to do this kind of things:

1. User interfaces are user interfaces, business logic is business logic and data are data. Keep it in mind! So, a three tier architecture is a strong idea to design software.

2. Use threads! Please, please, please, use threads!. Threads lets you do the hard work in background and offer a friendly and high-usability user interface.

3. Think in software evolution. Software *ALWAYS* evolves so, design easy-to-extend, easy-to-adapt, easy to change, architectures.

OK, after this Great Software Words , here is my design:

VB App ASP pages Future digitalTV?
| | |
-------------------------------------------- ...
|
ATL object
|
|
Window service
|
|
SQL-Server

1. VB app or ASP pages instance and exec an ActiveX (ATL simple object):

Dim x = new ActiveXObject("MyCOM.MyObject&quot
x.Exec()

2. ATL object sends a message to a windows service and returns

3. The windows service do the hard SQL work. I'm not sure if it will be better an stored SQLserver process to be called or the service itself.

Well, thats all. I hope it will be useful!

Regards.

Polu.