i want open the access file in my PB...what I can use?

Thx BB

MS Access... on a PC. Sadly, that's the only way.

Although it can be a VirtualPC :)

This MacWorld article may be of some interest to you... though it may not, depending on what you wish to do with your access files:
http://www.macworld.com/news/2006/01...iver/index.php

Hey didn't know about that one, good info, thanks.

I had to read the title twice to beleive this one :D Access files made compatible with Mac ! It sounded so impossible until this...

HOLY CRAP!!! Not that I like MSAccess, but at least that option is now available.

I've been asked many, many times to help people out with this exact problem. Now I have a cheap ($30) answer.

Note that the current version of that product provides read-only access to Access files. I.e. you can prepare reports, etc - but you can't add data.

It also looks like it just gives you an interface to the JET database--NOT any of the GUI interfaces, and (perhaps most importantly) any of the application-related VB code.

That latter would be a deal-killer for any Access database I've ever worked with. All the business logic is built with VB because, well, that's the only way you can do it in Access. Any other database and you'd use stored procedures, triggers, and the like...but not Access.

I'd go so far as to call this app dangerous. It looks like a very useful tool in certain limited situations, but also like it has the capability to cause more grief than good.

``Use with extreme caution only.''

Cheers,

b&

Why would you say thast its extremely dangerous if its read only ? I'm not very much used to Access (as every one has told me to stay far away from it) so I don't see how a read only access can make the app dangerous... Could you enlighten me ?

Because, all too often, the data that you would get by doing raw SQL queries isn't the data that the application is supposed to report. There's usually a lot of business logic built into these things--and, all too often, poorly designed business logic, at that.

For example, you might be recording, say, daily temperatures. But, after a month of recording, somebody notices that the card at the back of the thermometer has slipped so that everything reads four degrees higher than it really was. It's not unheard of to see people ``fix'' this problem by adding some VB code to the GUI such that everything before a certain date gets 4 added to it. Look at the data in the GUI, and everything's fine. Query the back-end, and you're hosed.

No, that's not the right way to deal with these sorts of things, but I've seen it all sorts of places--including in the accounting code of hundred-million-dollar companies.

Cheers,

b&

It's useful for snagging the raw table data so you can rebuild your solution in FileMaker though :)

Ah ok... dangerous in the sense that if the databse was badly done to start with, you mmay not see proper data ! Now is it me or that sounds like something that would almost only happen to Access databases since its the "easy" database software on Windows... a bit like FrontPage to design web pages ? ie that it lets people screw it up or design it very poorly without notification. :rolleyes:

In all fairness, I have FileMaker databases that are chock-full of data that isn't in the format that the end users see (and conceptualize) it. It's generally not so much an issue of "improper data" that needs to be massaged by a script as it is ignorance by the typical enduser of basic database architecture.

Our accountant thinks there is a unitary object called an "invoice" for job 56789, and that it has a specific socket in it for large-format proofs and their price, and another specific socket for the client and client address and so on. Of course there's nothing of the sort — there are line items of the invoice, each of which has a field that describes what the line is about, and a code that links the line to a separate table of products and their prices, and a code that links the line back to a separate table of jobs, the record of which has a field that links the job back to yet another table, this one of clients.

The production people think each job is a unitary object, but, similarly, all the tasks of the job are in a different file from the job record.

And even if you knew where the data was, architecturally speaking, if you viewed the Due Date field in raw form it would not say "1/19/06" or even "1/19/2006", but instead "732330" — rendering it as "1/19/06" is a formatting overlay established in layout mode, just as "January 19, 2006" is. And lots of fields that the user sees are calc fields that display the contents of various other fields depending on some variable — e.g., if there's a custom price for Client X for Greasey Widget #14, the price field is going to show that price when client = "Client X", rather than the standard price for Greasey Widget #14.

There are even fields that contain different results depending on global variables such as who the user is (established at logon) or what today's date is — data that is "state"-dependent in a way that isn't going to be accurate and current if you simply SQL the data from the static table file out to a matrix of columns and rows.

Hell, I'd hate to have to look stuff up in our database if I were deprived of the entire GUI, and I built the damn thing!

Im starting to see clearly that I'm not meant to be a database creator or admin... Just hearing you guys talking about it is enough !

And I've seen exactly the same sort of thing, time and again, in Access. It's not exactly the right way to do things...but it's the only way to do it with that particular kind of tool.

What I mean, of course, is that you should--nay, must have all your data normalized as you describe. But you should also have all the business logic built into stored procedures, views, triggers, and the like in the database itself. That way, one could just do a ``SELECT * FROM Invoices WHERE ID = 'A3742''' and get exactly what one would expect.

Manipulating data outside of the database is just asking for trouble...but, sadly, Access and FileMaker and similar tools just aren't capable of doing anything else.

In short, the data should go in the tables of the database. The business logic should go in the database's programmability features. Application code should be nothing more than UI niceties and getting the data to and from the database.

Displaying negative values in red? Do it in code. Calculating sales tax on a per-locality basis? Do it in the database. Applying volume discounts? Do it in the database--and store the original amount, the discount amount (dollar / percentage), and (only if necessary for performance) the calculated final amount.

Of course, if you've got a slow database link, it may be necessary to do all that at both ends, but what you do in the database is what matters, and what you do in the UI is just a duplicate effort to speed up appearances.

Cheers,

b&

Well, I tend to think like a database. (Hence my skillset and versatility in the trade). The database holds the real data. $439.96 really is the price of a Greasey Widget #4. It's just that that's not what you said you were interested in, you wanted to see the special price for Client X insofar as this is a Client X invoice. Doesn't change the fact that the (default) price for Greasey Widget #4 is $439.96, that's still totally true. The special prices for Client X function as an override. That price really is $396.04 per the same Greasey Widget #4, but that's only relevant if you want to know how much it costs Client X, and we think in general terms here. Don't ever ever ask me where the field is for the Client X price! You think I'm going to make special cases for individual occurrences? Nope, there are standard prices and there are custom per-the-client prices, architecturally speaking, with the latter overriding the former in the calc field that displays on your invoice, but there is no hardwired Client X price, architecturally speaking, anywhere in the system. Even if they were the only client that would have a custom price, I would build an architecture that would also handle Client Y in the event that Client Y also would have custom prices. The relevant parameter is "clients who get custom prices", NOT whether or not the client is Client X. I do not do hard-wiring by specific value of a field, it's bad coding!

Oh, and FileMaker is nicer than Access (in a dozen other ways but for the moment I speak of:) FileMaker has calculation fields which are part of the table structure, not just part of the GUI / reporting mechanism, and into which you can build very complex logic. Things you'd think of as verbs that exist as nouns. The entire HTML code of a web page referencing fields and images, or the code of an AppleScript or Unix command-line instruction, not assembled on an as-needed scripted basis but just calculated as a noun, as part of the table, referencing other fields and calculable parameters and always just sitting there for whenever you want to reference it.

Hum... You guys are heros for dealing with this all the time... I don't see where I'd get the patience to have to use such a system that has more twists and turns than straightways...

I'm cowed...

Naah... You can do some incredibly complex things with databases, but you can figure out how to do basic stuff without cracking the manual.

They're almost as simple as spreadsheets. (Of course if you waded into a conversation about pivot tables and visual-basic macros and conditional cell ranges, I suppose Excel could look frightening too)

Well...I do have a mantra that I find helps. Tremendously.

Billable hours, billable hours, billable hours, billable hours....

Cheers,

b&