[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

mm

7/21/2012 8:11:00 PM

Hello,

I use DAO 3.6 and an Access database.

I needed to perform a lock at register level, and not as page level as DAO
does.

The only solution that I found, requires a reference to ADO, as stated here:
http://support.microsoft.com/kb/30...

I have several ADO versions registered on this machine: 2.0, 2.1, 25, 2.6,
2.7 and 2.8

I used 2.8 and it worked fine. But what problems could I have with this
reference to ADO when distributing the program? What version should I use?
Is there any problem that I should be aware of about ADO?

Thanks.


53 Answers

mm

7/21/2012 8:14:00 PM

0

Sorry about the title, I was thinking in Spanish.

After two hours trying to make something that should be simple, as a lock at
register level, I didn't realize that I wrote the subject half in Spanish.


Ralph

7/21/2012 10:08:00 PM

0

On Sat, 21 Jul 2012 17:11:19 -0300, "Eduardo" <mm@mm.com> wrote:

>Hello,
>
>I use DAO 3.6 and an Access database.
>
>I needed to perform a lock at register level, and not as page level as DAO
>does.
>
>The only solution that I found, requires a reference to ADO, as stated here:
>http://support.microsoft.com/kb/30...
>
>I have several ADO versions registered on this machine: 2.0, 2.1, 25, 2.6,
>2.7 and 2.8
>
>I used 2.8 and it worked fine. But what problems could I have with this
>reference to ADO when distributing the program?

The target platform would have to have MDAC 2.8 installed. Since MDAC
2.8 was included with Windows XP, and was the upgrade offered by most
MS Products for Win2000, you would have to run into someone hidding in
a cave for the last 8-10 years for them to not have MDAC 2.8
installed. But you can download the MDAC install package.

>What version should I use?

You can use ADO 2.5 and stretch the time back another 5-6 years. ADO
2.5 is the version used by most developers that are concerned about
targets not having ADO 2.8 installed.

Personally I don't agree with that view. It isn't the extra features
that makes having ADO 2.8 available desirable - it is all those bug
fixes and security updates between MDAC 2.5 and 2.8 - do your target a
favor - install MDAC 2.8 if it is not currently there.


>Is there any problem that I should be aware of about ADO?
>

Nope. Except the usual. ADO is out of process and will be a tad slower
than DAO for JET. Make sure you use the latest 'n greatest "OLE DB for
Jet" Provider.

-ralph

mm

7/21/2012 10:21:00 PM

0


"ralph" <nt_consulting64@yahoo.com> escribió en el mensaje
news:h19m085880dr3ik9m4n000jvukt4i9ei2u@4ax.com...

>>I use DAO 3.6 and an Access database.

>>The only solution that I found, requires a reference to ADO, as stated
>>here:
>>http://support.microsoft.com/kb/30...

> The target platform would have to have MDAC 2.8 installed. Since MDAC
> 2.8 was included with Windows XP, and was the upgrade offered by most
> MS Products for Win2000, you would have to run into someone hidding in
> a cave for the last 8-10 years for them to not have MDAC 2.8
> installed. But you can download the MDAC install package.

That was my concern.

>>What version should I use?
>
> You can use ADO 2.5 and stretch the time back another 5-6 years. ADO
> 2.5 is the version used by most developers that are concerned about
> targets not having ADO 2.8 installed.
>
> Personally I don't agree with that view. It isn't the extra features
> that makes having ADO 2.8 available desirable - it is all those bug
> fixes and security updates between MDAC 2.5 and 2.8 - do your target a
> favor - install MDAC 2.8 if it is not currently there.

But I'm not using ADO at all, I'm using it just to make a connection and to
close it inmediately just when the program starts.

Dim cnn As ADODB.Connection

Set cnn = New ADODB.Connection
cnn.Provider = "Microsoft.JET.OLEDB.4.0"
cnn.Properties("Data Source") = App.Path & "\Bases\MyDatabase.mdb"
cnn.Properties("Jet OLEDB:Database Locking Mode") = 1
cnn.CursorLocation = adUseServer
cnn.Open

Set gWorkSpace = DBEngine.Workspaces(0)

Set gBase = gWorkSpace.OpenDatabase(App.Path & "\Bases\MyDatabase.mdb",
False, False)

cnn.Close
Set cnn = Nothing

And that's all I use ADO for.

Isn't there any other way to lock a record in a table with DAO other than
doing this http://support.microsoft.com/kb/30... ?


Ralph

7/22/2012 4:54:00 AM

0

On Sat, 21 Jul 2012 19:21:09 -0300, "Eduardo" <mm@mm.com> wrote:
>
>But I'm not using ADO at all, I'm using it just to make a connection and to
>close it inmediately just when the program starts.
>
<snipped>
>
>And that's all I use ADO for.
>
>Isn't there any other way to lock a record in a table with DAO other than
>doing this http://support.microsoft.com/kb/30... ?
>

Forgot about that hack.

There is probably a way to talk to Jet (the hidden global object) in
VB - after all it is all just one's and zero's below the surface - but
why bother?

You would likely need another language/platform to get at it, you
would have to go poking around in mostly undocumented territory, and
finally I doubt anything you could come up with would be as simple and
robust as those few lines of code.

Use ADO and don't worry about it. For the few that complain, provide
these URLs.
For ADO
http://www.microsoft.com/en-us/download/details.as...
For Jet Provider
http://support.microsoft.com...

-ralph

mm

7/22/2012 12:12:00 PM

0


"ralph" <nt_consulting64@yahoo.com> escribió en el mensaje
news:ch0n085pjs19uf4s6djjg37fupvr7jthvp@4ax.com...

>>Isn't there any other way to lock a record in a table with DAO other than
>>doing this http://support.microsoft.com/kb/30... ?
>>
>
> Forgot about that hack.
>
> There is probably a way to talk to Jet (the hidden global object) in
> VB - after all it is all just one's and zero's below the surface - but
> why bother?

That's what I thought, perhaps using another, a light weight database driver
that let me do the same "hack".

>
> You would likely need another language/platform to get at it, you
> would have to go poking around in mostly undocumented territory, and
> finally I doubt anything you could come up with would be as simple and
> robust as those few lines of code.
>
> Use ADO and don't worry about it. For the few that complain, provide
> these URLs.
> For ADO
> http://www.microsoft.com/en-us/download/details.as...
> For Jet Provider
> http://support.microsoft.com...

I'm planning to distribute this program with MMM (Make my Manifest), do you
think that could be a problem with ADO for running in this way?

I have said that I would migrate the application and database to SQLite, but
I don't know if I'll have the time to do that before the first release.


Ralph

7/22/2012 2:18:00 PM

0

On Sun, 22 Jul 2012 09:11:44 -0300, "Eduardo" <mm@mm.com> wrote:

>
>"ralph" <nt_consulting64@yahoo.com> escribió en el mensaje
>news:ch0n085pjs19uf4s6djjg37fupvr7jthvp@4ax.com...
>
>>>Isn't there any other way to lock a record in a table with DAO other than
>>>doing this http://support.microsoft.com/kb/30... ?
>>>
>>
>> Forgot about that hack.
>>
>> There is probably a way to talk to Jet (the hidden global object) in
>> VB - after all it is all just one's and zero's below the surface - but
>> why bother?
>
>That's what I thought, perhaps using another, a light weight database driver
>that let me do the same "hack".
>

Maybe. I thought of checking out DirectData's and a few other 3rd
party drivers, but then realized what would be the point? You would
still be back to insuring the target machine had the required
component - in this case it is very unlikely they would, and they are
expensive. ADO is free. <g>

Writing your own Provider/Driver isn't that big of a deal, most of it
is boilerplate, but isn't a trivial exercise either. You would have to
obtain the SDK, spend time reading, writing, then testing, and you are
still back to installing the component.

On further reflection I believe for simply setting a property it might
be done easier than I thought - but again - why?

>>
>> You would likely need another language/platform to get at it, you
>> would have to go poking around in mostly undocumented territory, and
>> finally I doubt anything you could come up with would be as simple and
>> robust as those few lines of code.
>>
>> Use ADO and don't worry about it. For the few that complain, provide
>> these URLs.
>> For ADO
>> http://www.microsoft.com/en-us/download/details.as...
>> For Jet Provider
>> http://support.microsoft.com...
>
>I'm planning to distribute this program with MMM (Make my Manifest), do you
>think that could be a problem with ADO for running in this way?
>

Nope. Just leave ADO out of it. It will be there.

>I have said that I would migrate the application and database to SQLite, but
>I don't know if I'll have the time to do that before the first release.
>

Then wasting time writing your own or purchasing someone else's is
definitely not worth it. IMHO.

-ralph

mm

7/22/2012 2:48:00 PM

0


"ralph" <nt_consulting64@yahoo.com> escribió en el mensaje
news:542o081higpqhbld6r06k7ht0isj7j8jtq@4ax.com...

> Then wasting time writing your own or purchasing someone else's is
> definitely not worth it. IMHO.

I really don't understand your point when you say "not worth".
If I'm going to distribute the program with MMM, what do you mean with "not
worth"?

In any case, if I require the program to be installed (not MMM), the
installation must be smooth, not telling the user to go to somewhere to
install a file separately, even if I provide it.
This program is for people that not necessarily know much about software,
it's not for a corporate environment where an admin will install everything
with the instructions step by step that I can provide.

It must be a double click, install and run.


mm

7/22/2012 3:07:00 PM

0


"Eduardo" <mm@mm.com> escribió en el mensaje
news:juf2cp$lkd$1@speranza.aioe.org...

Isn't there some other way to know if another user is working with some
specific data other than locking a register?

I need to do something like this:

Suppose that there are two tables in the database: Invoices and
Invoices_Items

If one user goes to edit an invoice, he could be changing data in the
invoices items's table, adding new ones, or deleting records.
So, I want to prevent other users to go to work with the same invoice at the
same time, but still allowing them to work with other invoices.

My idea was to put the record of the Invoices table on Edit mode while the
user is working with that invoice. So if other user tries to edit the same
invoice, there is a trappable error that I can use to tell the user that
there is currently another user working with that invoice.

The problem is that DAO locks many records, not just that one.

Do you think of another way to check if another user is currently working
with some specific invoice?


mm

7/22/2012 4:02:00 PM

0


"ralph" <nt_consulting64@yahoo.com> escribió en el mensaje
news:542o081higpqhbld6r06k7ht0isj7j8jtq@4ax.com...

I found another hack not requiring ADO:
http://www.vbforums.com/showpost.php?p=467483&p...

I needed to add 7 dummy text fields with length = 255 and default value to
"aaaaaaaaaaa..." and to fill the existent records. But... it only worked
when I set the Unicode Compression to No.


Schmidt

7/22/2012 5:59:00 PM

0

Am 22.07.2012 17:06, schrieb Eduardo:
> "Eduardo" <mm@mm.com> escribi� en el mensaje
> news:juf2cp$lkd$1@speranza.aioe.org...
>
> Isn't there some other way to know if another user is working with some
> specific data other than locking a register?
>
> I need to do something like this:
>
> Suppose that there are two tables in the database: Invoices and
> Invoices_Items
>
> If one user goes to edit an invoice, he could be changing data in the
> invoices items's table, adding new ones, or deleting records.
> So, I want to prevent other users to go to work with the same invoice at the
> same time, but still allowing them to work with other invoices.
>
> My idea was to put the record of the Invoices table on Edit mode while the
> user is working with that invoice. So if other user tries to edit the same
> invoice, there is a trappable error that I can use to tell the user that
> there is currently another user working with that invoice.
>
> The problem is that DAO locks many records, not just that one.
>
> Do you think of another way to check if another user is currently
> working with some specific invoice?
>

Just introduce an additional "Locks"-Table in your DB - and
handle the locking on the clientside yourself.

Such a table could contain Fields as:
TableName (e.g. in your case "invoices")
RecordID (the ID of the record of the table in [TableName]
UserID
TimeStampLockStart
TimeStampLockExpires

Then on each "Edit-Request" for a given RecordID in table
[invoices], you would take a look at your new DB-Table, whether
the invoice-table-RecordID in question already has an entry in your
new [Locks]-table ... if not, just make such an entry immediately
(within the same transaction you just used in your Read-Select,
to check if the given RecordID is already placed within [Locks]).

After your edit-session is finished, delete the entry with the
current invoice-RecordID from your Locks-Table.

This should work well enough - and with the TimeStamps you
could ensure, that no User is blocking that Record in question
overly long, even when the client-machine in question has e.g.
a powerfailure - or the user in question is inresponsible and
enters Edit-Mode (without finishing it) and moves off to lunch
for an hour.

Olaf