By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,486 Members | 2,061 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,486 IT Pros & Developers. It's quick & easy.

Communicating with Act

P: n/a
Hi all,
I have an access xp database that needs to update a few things in an
ACT database from time to time. I downloaded the sdk, but it's in
..NET. So, is there an object that will work with vb 6? I also read
the the act files are dbf, so could I just modify those as needed? I
am an advanced programmer and need to know what the best way to
approach this is. Anything you can do to point me in the right
direction would be really helpful.
Thanks
Pachydermitis

Nov 13 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
..dbf is dBase table format to which Access can link (at least, for most
versions of dBase) if you have permissions. I have, a few times, been able
to link to .dbf tables in commercial packages and use them just as if they
were my own Access tables. The hard part was figuring out cryptic field
names. <G>

In most of those cases, I was not able to employ the indexes, but
performance was not an issue because of the few records being updated.

Larry Linson
Microsoft Access MVP
"Pachydermitis" <de******@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Hi all,
I have an access xp database that needs to update a few things in an
ACT database from time to time. I downloaded the sdk, but it's in
.NET. So, is there an object that will work with vb 6? I also read
the the act files are dbf, so could I just modify those as needed? I
am an advanced programmer and need to know what the best way to
approach this is. Anything you can do to point me in the right
direction would be really helpful.
Thanks
Pachydermitis

Nov 13 '05 #2

P: n/a
Thanks Larry,
It looks like the the new versions of act use SQL Server 2000 not dbf
anymore. Connection would be easy except I cannot find the sql pwds
are different than the ACT pwds for any of the logins.
Thanks in advance
Pachydermitis

Nov 13 '05 #3

P: n/a
"Pachydermitis" wrote
It looks like the the new versions of act
use SQL Server 2000 not dbf anymore.
Connection would be easy except I can-
not find the sql pwds are different than
the ACT pwds for any of the logins.


I don't know enough about SQL Server security to hazard a guess how valuable
the connection would have to be for you to buy something that would break
the security, or if you can, within reason.

I just read there was a big international raid on "crackers", so any cracker
that was interested in ACT may have been nabbed by the long arm of the law,
along with those who did software cracks for fee or free.

As I recall, the value for Jet data ranges from nothing (Access 97) to about
US$150 (later versions). That is why you need to prevent unauthorized
persons from having any access to a Jet database. If they can make a copy,
they can carry it off and crack it to get the data.

Larry Linson
Microsoft Access MVP


Nov 13 '05 #4

P: n/a
"Pachydermitis" <de******@hotmail.com> wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:
It looks like the the new versions of act use SQL Server 2000 not
dbf anymore. Connection would be easy except I cannot find the
sql pwds are different than the ACT pwds for any of the logins.


ACT used to have a developers toolkit with an automation interface
that was the preferred method for interfacing with ACT files. I'd
assume that they would not have discontinued that with the change of
the data storage format.

My experience, however, was that automation interfaces of this type
work great when you want one specific item, but is very inefficient
for the retrieval of large recordsets.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #5

P: n/a
David
You are right, they do still have a tool kit, and it's just a .net dll
that (I'm sure) writes a record to the db using standard ADO. And you
are also right in that for a couple writes I'm OK, but it will be a
problem for more. So how on earth do I get into MY OWN database? :(
Thanks
Pachydermitis

Nov 13 '05 #6

P: n/a
"Pachydermitis" <de******@hotmail.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:
You are right, they do still have a tool kit, and it's just a .net
dll that (I'm sure) writes a record to the db using standard ADO.
And you are also right in that for a couple writes I'm OK, but it
will be a problem for more. So how on earth do I get into MY OWN
database? :( Thanks


I don't think you do -- you either use their defined interface or
you *don't*.

I wouldn't want you bypassing my interfaces to *my* database,
either, so I don't see that ACT is doing anything wrong there.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #7

P: n/a
David,
You are right, they are not doing anything 'wrong'. This Access
database will soon be migrated to an sql backend and then a web
interface. In order to have the sql server talk to itself using a .Net
app I will have to open some pretty big security holes in the server.
This will also be a huge performance drain. I'm hoping that the ACT
developers have built in some advanced flexibility with this in mind -
and that one of you advanced users knows about it.
Thanks
Pachydermitis

Nov 13 '05 #8

P: n/a
Application vendors often build custom interfaces to their data in
order to enforce business rules or support associated processes such as
"home grown" synchronization mechanisms. In such cases it is usually
safe to bypass them for _reading_ the data (e.g., for reporting) but
not for _writing_ it. If you are going to be updating live Act! data
you should seriously consider sticking with the vendor's API.

Nov 13 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.