has anyone here used OpenOffice Base?

[Kuciwalker]

We do a fair amount of 'data work' in Access, particularly on the health side - not using it as a persistent DB but just as a way to process claims and generate (often complicated) reports. Access has a horrendous UI to the point that I write all of my queries in Notepad++ and then paste them in. Has anyone here used Base and, if so, is it any better? I don't care at all about query wizards and crap like that, I just want a good SQL IDE that's integrated with my database.

[Asher]

has anyone here used OpenOffice Base?

[Asher]

It's my understanding that Access is just a front-end for a Jet DB. There must be some SQL IDEs that support that.

Hell, I wrote an app to interface with a Jet DB back in 2002 in VC++ 6.0. Maybe you could just roll you own one as a project. Would still be better than Base, especially if all you're doing is SQL writing and no GUI nonsense.

Does DBArtisan support Access or Jet?

[onodera]

I don't understand. You say you use Access to create reports, but you say it's the query builder that is the problem.
I would install MS SQL Server Express with Tools. It has good IDE and its SQL dialect is very close to the one in Access. Oracle XE is also a viable candidate (and I like PL/SQL more than T-SQL, even with no TOP keyword), but Oracle's own SQL IDE is terrible. TOAD is quite good (not as good with Intellisense as MS IDE are, though), but expensive and you need a separate piece of software to generate pretty reports.

[MikeH]

We do a fair amount of 'data work' in Access, particularly on the health side - not using it as a persistent DB but just as a way to process claims and generate (often complicated) reports.

Oh God.

The amount of times I've been in the aftermath of a situation like this.

[Aeson]

i've used base. It sucks. They say u get what u pay 4, but in this case free is still a rip off

[Kuciwalker]

Re: Asher and onodera:

I'm not sure I described the situation clearly in OP. Basically, my workflow is something like this:

1) Get a bunch of insurance claims (health side) or employee/participant data (pension side) from the client, in a big text file.
2) Import to Access, or (more commonly) link access to the file, setting up a data layout.
3) Write some queries to perform whatever computation I need to do with the data (e.g. select sum(amount paid) from claims group by procedure code). These computations are usually somewhere in the vicinity of 5-20 queries long (chained).
4) Someone else takes the results of (3) and does stuff with it, then asks me to run more queries, etc. Eventually I am done, I save the Access file to our archive server and delete the data files off my hard drive.

The point is that (3) is a ****ing pain in the ass in Access because it's a godawful IDE. But I don't want an IDE to manage e.g. a MySQL server running on my computer, because then if I have to share my work with anyone else in the firm it's much more complicated than just giving them some data files and the Access database with the links and queries.

[Kuciwalker]

MikeH: I agree, but there isn't really an alternative. SQL is the only reasonable paradigm for these calculations, and there's very little we can do to standardize any of the steps because every client and every insurance company has their own data layouts and needs different calculations done.

[BlackCat]

Re: Asher and onodera:

I'm not sure I described the situation clearly in OP. Basically, my workflow is something like this:

1) Get a bunch of insurance claims (health side) or employee/participant data (pension side) from the client, in a big text file.
2) Import to Access, or (more commonly) link access to the file, setting up a data layout.
3) Write some queries to perform whatever computation I need to do with the data (e.g. select sum(amount paid) from claims group by procedure code). These computations are usually somewhere in the vicinity of 5-20 queries long (chained).
4) Someone else takes the results of (3) and does stuff with it, then asks me to run more queries, etc. Eventually I am done, I save the Access file to our archive server and delete the data files off my hard drive.

The point is that (3) is a ****ing pain in the ass in Access because it's a godawful IDE. But I don't want an IDE to manage e.g. a MySQL server running on my computer, because then if I have to share my work with anyone else in the firm it's much more complicated than just giving them some data files and the Access database with the links and queries.

I've heard rumours that there was people doing things like that, but I have never belived it.

What you are describing is material for a note in http://thedailywtf.com/

[Asher]

I would be more inclined to do this more programmatically, is all.

SQL Server supports exporting to Access, IIRC. Is the file just CSV? If you have standardized formats, I'd whip up a SSIS (SQL Server Integration Services) project in C# to transform the data as needed and load it in SQL server. Then use a real SQL IDE to do your work, and when done just export the DB to Access format.

[BlackCat]

Asher, it's this that really worries me :

But I don't want an IDE to manage e.g. a MySQL server running on my computer, because then if I have to share my work with anyone else in the firm it's much more complicated than just giving them some data files and the Access database with the links and queries.

[Asher]

I don't know if insurance companies have gotten around to networks yet. Patience...

[BlackCat]

Well, I guess that intenational important insurance copanies has learned such things. Wonder what kind of company Kuci are working for - it must be a major since KH and Kuci apparently has common fellatio

[Hauldren Collider]

Oh lord, openoffice base. Don't even get me started on openoffice in general, let alone openoffice base.

[onodera]

Re: Asher and onodera:

I'm not sure I described the situation clearly in OP. Basically, my workflow is something like this:

1) Get a bunch of insurance claims (health side) or employee/participant data (pension side) from the client, in a big text file.
2) Import to Access, or (more commonly) link access to the file, setting up a data layout.
3) Write some queries to perform whatever computation I need to do with the data (e.g. select sum(amount paid) from claims group by procedure code). These computations are usually somewhere in the vicinity of 5-20 queries long (chained).
4) Someone else takes the results of (3) and does stuff with it, then asks me to run more queries, etc. Eventually I am done, I save the Access file to our archive server and delete the data files off my hard drive.

The point is that (3) is a ****ing pain in the ass in Access because it's a godawful IDE. But I don't want an IDE to manage e.g. a MySQL server running on my computer, because then if I have to share my work with anyone else in the firm it's much more complicated than just giving them some data files and the Access database with the links and queries.

Holy crap.
Doesn't your company have a database server or instance for small applications? Just ask for a new DB there for your needs. You can use whatever you want to develop there, and people can use Access to view the results. OO Base is a terrible Access clone.