help with installation of my application and problems in my pc

[angelpr23]

dear all,
i am beginer in vb6 programming and this is my first application. I created an application in vb6 wich hadles a mdb database created on visual data manager->microsoft access->version 7.0 MDB. I navigated into control panel -> administrative tools->datasources (ODBC) and added my database. And this because i used microsoft ole db provider for odbc drivers in connection string.
I wanted to create an installation for this application and i did this with package & deployment wizard. My problem is that i wanted the installation program to add my database into control panel -> administrative tools->datasources (ODBC) as i did it alone. And this because i'm thinking to install it in another computers later. So what can i do for this? Also, i saw in a treat i don't remember which, someone tell about interdev to make up an installation file. I tried to install it from visual studio 6 cd and when the installation completed successfully appeared a message says that some files of windows replaced with files of cd. For the balance of my system put the windows cd now. I dont know what exactly happened but i was afraid and i m still too. I put the windows cd in diskdriver and the message dissapeared from desktop. Any help with all these please? I didn't know what to do with windows cd and i did nothing. The only i did is to unistall the interdev. But i don't know if have problems with my pc in the future. My operating system is Windows XP SP2. Any help with my application installation and my pc problem will be very much appreciated.

Thanks everyone
in advanced.

 

[ChewDoggie]

You may want to look into the INNO Setup Installer. It's a lot more customizable than the default installer associated with VB6.

Look here for more information:

http://www.jrsoftware.org/isdl.php

HTH


AMACycle

American Motorcyclist Association

http://www.ama-cycle.org

 

[harebrain]

Your real problem is that you missed the point of using OLEDB: ODBC is the old technology that shackles you to DSNs. If you use OLEDB natively, there is no DSN to set up.

 

[BobRodes]

Yeah, try using the ole db provider for access (JET), and losing all that odbc stuff. In fact, I wouldn't have used odbc ever, even when it was new technology, to open access files.

Don't use the Package and Deployment Wizard that comes with VB. INNO is probably a great choice, never used it but very often recommended here. Alternatively, the Visual Studio Installer is based on InterDev and allows you to create .msi (microsoft installer) files from your VB program.

HTH

Bob

 

[harebrain]

The operative words I omitted from my previous post are "DSN-less connection." See

http://www.carlprothman.net/Default.aspx?tabid=87#OLEDBProviderForMicrosoftJet

 

[angelpr23]

Thank all of you replyed me.
I downloaded inno us netherlands ispack-5.1.11.exe.
Is it nessary for creating the setup of my application to use it ole db provider for access (JET)? Or let it as it is with odbc? If i well understood ole db provider for access (JET) is newer technology than ole odbc provider. I 'm just thinking that i will lose time if i try to use ole db provider for access (JET) and if i do this have i to create again my database in microsoft access not as i created it from visual data manager? Does this mean that i will have to proceed in corrections in my code?

 

[BobRodes]

ODBC has to go through JET to get to the Access files. The way that ODBC would work is this:

ADO
OLEDB provider for ODBC
ODBC to JET translation
JET accesses data

The way that JET would work is this:

ADO
OLEDB provider for JET
JET accesses data

So it's better to use the JET provider. Now, to answer your questions: I don't use Visual Data Manager, but I'm going to say no, you don't. If you have an .mdb file, that's your database. To access it via the OLEDB provider for JET, change the ConnectionString property in your ADO Connection object. For more info, visit

http://www.connectionstrings.com.

So, my advice to you is go ahead and lose a little time to get the job done right. In the end you will find that you have a much simpler solution and will have learned some things that will stand you well in the future.

 

[angelpr23]

Thank you very much BobRodes,
i understood that is better to use OLEDB provider for JET than OLEDB provider for ODBC and this i am going to do.
I just have anotherone question in my mind, i have some forms that displays all records from every table using ado data control, my data base is in this file path C:\Program Files\Microsoft Visual Studio\VB98\mydb.mdb
is included in ado data control's connection string and ado data connection (in my code) too. If i create the setup file through inno and a user tries to install it on his computer, if he changes the setup filepath is it going to cause problems in execution of my application? For example not displaying all records because it could not find the database in properly filepath? And generraly causes buggins in connection sting either in ado data control's connection string either in connection string of ado connection (in source code)?
Thank you much again.

 

[SBerthold]

You need to set the datacontrol's database name dynamically:
Something like:

Dim myPath as string

myPath=App.Path & "\MyData.Mdb"
Data1.Databasename = myPath

 

[angelpr23]

I am using ado data control not data control.
Ado data control doesn't provide databasename property.
Is it possible to define the connection string of ado data contol with code or not? i tried this in form load

Dim myPath As String
myPath = App.Path & "\Mydb_new.Mdb"
AdoCust.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & myPath & _
"Persist Security Info=False"

but i am getting error odbc "does not located the data source file name and it has not defined the default driver program."
Any help please?

 

[SBerthold]

Run your program in the IDE, open a form which uses an ADODC and then go into break mode.

In the immediate\debug window type:

?AdoCust.ConnectionString

and hit RETURN

This will be an example on how the string looks like.
After setting the ConnectionString in code, call the AdoCust.refresh method.

You will also need to removed all data controls connection strings in the control's property window, otherwise because the connection info in the properties window has preference, the user gets an error if the database is not there where it is defined in the properties window.

 

[angelpr23]

Thank you much SBerthold that workes, i forgot to set a ";" in "\Mydb_new.Mdb;" Do i have to do the same with datasource property of ado data control? Can i use it entirely in code for example AdoCust.RecordSource = "select * from customers;" and not from properties window?

 

[BobRodes]

You can set the RecordSource property in code, but you then have to refresh the data control. (AdoCust.Refresh) What you're doing in effect is changing a sql command, and then re-running it.

I would not use the Data control in general. Rather, I would use ADO objects.

HTH

Bob

 

[angelpr23]

Thank you again BobRodes.
I am using ado data control for displaying reasons. To be beautiful. I think you mean to use the ado data control at all and use ado recordset objects and draw command buttons in the form to navigate through records. If i well understood the difference between these ways is in the speed. I mean that using ado recordset there is less time consuming in processor, so the application runs ruppidly and effectively than using ado data control. A question about refresh, must i refresh it after datafield values of textboxes or can i do it before, after set the recordsource property?

 

[SBerthold]

>I am using ado data control for displaying reasons. To be beautiful

There is really nothing aginst using the control for this reason...However, please do yourself a favour and remove the ConnectionString from the properties window, and set it in code, and use a Static Clientside cursor and then refresh, and then set:
ADODC1.Recordset.ActiveConnection = Nothing

Or better, create the Connection and Recordsets in code using a client side cursor and set: ADODC1.Recordset=myRS, after setting the myRS.ActiveConnection to nothing.

Do your updates using the in-code created Connection object, or use BatchUpdating using the in-code created recordset object.

Doing this avoids the ADODC from taking control of things as happened under DAO, or from opening extra needless connections, and you then have control as when using a normal recordset object, and still have the advantage of using the ADODC navigation buttons.

Anyone already using in-code created Connection and Recordset objects, with client side static cursors can just pop an ADODC onto the form, with-out(!) setting any properties in the property window, and then in code just set it's ADODC1.Recordset to the Recordset object created in-code - Instant navigation buttons with-out any ADODC side affects, because the ADODC1.Recordset takes over all the properties of the in-code created Recordset object! Nothing else changes.

 

[angelpr23]

In form load event i have done this in order to display all records in textboxes of my form:
Private Sub Form_Load()
AdoCateg.ConnectionString = conn.ConnectionString
AdoCateg.RecordSource = "select * from categories;"
AdoCateg.Refresh
For i = 0 To FuncTxt.UBound
Set Txt(i).DataSource = AdoCateg.Recordset
Next i
Txt(0).DataField = "CategoryID"
Txt(1).DataField = "CategoryName"
Txt(2).DataField = "Description"
Set AdoCateg.Recordset.ActiveConnection = Nothing
End sub

i do use property window of ado data control (adoCateg) at all. This works right, although if its better to create a recordset and set it to ado data conrtol recordset like this ADODC1.Recordset=myRS i will do it. I want to tell me if the code in form load event i wrote above using adodata control with code not in property window seems to you right.

I have a module in my program i have created there the connection of my db in a public function as you can see, and i call it when the program loads and close it when the program unloads. So i can access it from anywhere in my code (in design time of cource).

Public Sub ConnectionDb()
conn.ConnectionString = "Data Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Provider=MSDataShape;" & _
"Persist Security Info=False;" & _
"Data Source=" & App.Path & "\mydb_new.mdb;"
conn.CursorLocation = adUseClient
conn.Open
end sub

Thank all of you in advanced.

 

[SBerthold]

Now we are getting off-topic, or I guess I am. So any further posts not really pertaining to the installation of your program and problems with that installation and the datasource location used, need to be started in a different thread.

So, to close this up:

>i do use property window of ado data control (adoCateg) at all

I assume you meant to say "...not at all..."

>Set Txt(i).DataSource = AdoCateg.Recordset

This should come after the setting the DataFields, otherwise, unless the DataFields were already assigned in the control's property window, they will not bind.

Because you use a client side cursor for the connection, then the recordset will automatically also default to a client side static cursor, but to make the code easier to read, and to also avoid mistakes, you might want to explicitly set these for the recordset:

AdoCateg.CursorLocation = adUseClient
AdoCateg.CursorType = adOpenStatic 'a Client side cursor will always be static.

Then you will need to use an Execute sql statement off of the connection object, or the Recordset's UpdateBatch method to update the data back to the db table.

To use UpdateBatch, you will need to set the cursor's LockType prior to opening it, to:

AdoCateg.LockType = adLockBatchOptimistic

Other than that, I do not see any problems with the manner in which you are using the ADODC, as it is not bound to the data source.

When you go into Edit or AddNew mode, you will want to either disable the ADODC navigation controls, so validation can properly be achieved in the control's validation events and when your "cmdUpdate" is clicked, cancelling if needed, or do this using the ADODC events to implement validation prior to the data being actually updated (though I would prefer to using the events straight from a recordset object and not the ADODC, which I do not use at all).

Private Sub rsAdo_FieldChangeComplete
Private Sub rsAdo_WillChangeField
Private Sub rsAdo_WillChangeRecord
Private Sub rsAdo_WillChangeRecordset

Once again, please start a new thread for any further questions not pertaining to the opening question.

 

[angelpr23]

Thank you much SBerthold

 

[BobRodes]

I agree with SB that binding is the reason not to use the Data Control.

Bob

 

[SBerthold]

I do not see where I said that, or even implied it - but sorry if I did cause anyone to think that binding, or the use of ADODB Data Control, is not good or shouldn't be used - The only thing I would mean to say, is that if it is used, it should be used "properly" in order to avoid the above problems, among many many others - especially those problems that were very difficult to avoid under DAO, and the fact that it is used carelessly, often thanks to MS examples, and the "simplicity" of being able to use it.

I did state that the ADODC "... is not bound to the data source", meaning the DB table, but it is still bound to the cursor and its data, as with any in-code recordset object, which if desired could also be bound directly to a data source.

The latest problems angelpr23 was having did not have anything necessarily to do with the ADODC directly, and I do not think that the OP really did either.