Using Access just to organise data? (1 Viewer)

[Cicak]

Hi,

I'm wondering if it is possible if some programme, maybe in VBA, can be used to manipulate data in a database, such that the database has got several different normalized tables but no forms. Can programming be used to create some sort of interface that gets information from and enters information into these Access tables? What programming language would be best for this purpose?

Thanks in advance!
Regards.

P.S. As for me I don't know much about programming... It's somebody who does who asked me to find out about this..

 

[georgedwilkinson]

Yes, Access can be used as a back end to many different programming languages.

VB, VB.Net, C#.Net, ASP, ASP.Net, Java, JSP, and PHP are some of the more popular "languages" that are easy to hook into Access. "Best" depends on what you are doing and what your infrastructure is like. Oh, and personal preference.

 

[Cicak]

Thanks very much for the advice. I'll do some reading up.

Cheers

 

[Call_Me_Sam]

Hi,

P.S. As for me I don't know much about programming... It's somebody who does who asked me to find out about this..

George answered this but the P.S. pricked my curiousity...Cicak..someone else who knows about programming not knowing about linking to a database system? asks you to find out when you know even less?

 

[georgedwilkinson]

George answered this but the P.S. pricked my curiousity...Cicak..someone else who knows about programming not knowing about linking to a database system? asks you to find out when you know even less?

I was kinda wondering about that myself. My logic was that he was conducting research on a business venture. If that's the case, he'd need to know what kind of talent to hire to make the concept a reality, and, more important, how much that type of talent costs.

 

[Call_Me_Sam]

I was kinda wondering about that myself. My logic was that he was conducting research on a business venture. If that's the case, he'd need to know what kind of talent to hire to make the concept a reality, and, more important, how much that type of talent costs.

hmm sounds a good idea...some'one hiring knows about programming but doesn't do much themselves..asks some'one perhaps as a means to enhance their knowledge...then both gain something..

 

[Cicak]

Well actually this is the same database that I've been trying to get up for some time, the normal Access way. Someone new in the company (more senior than myself) prefers that we use Access as a back end instead as he'll most likely be administering the database and he's familiar with some programming languages but not really with Access. And since I don't know programming he'll probably be 'taking over' the database then.
Yeah, thanks for the help!

 

[georgedwilkinson]

Please be aware that I say this in all gentleness and only with your best interests at heart.

<soapbox>
Beware! I know more programming languages and environments than I can count and I can say, unequivocably, that there is no easier to develop in environment than Access. Same with maintenance. I highly recommend Access, especially if you don't know what you're doing.

Another approach is to develop/prototype your system in Access and then convert it to another platform. That way, you at least get the fast development time and prototyping abilities that Access just kinda has built in as a template for your other programming environment.

Microsoft has spent billions of dollars plugging features into Access that just work out of the box. There is absolutely no way that you'll ever be able to put as many features into custom written software as they have already built in, as long as you buck the trend of most Access developers and use the built-in functionality.
</soapbox>

I hope this helps you make a decision. If you need help with Access development, we're here to help guide you.

 

[Cicak]

Please be aware that I say this in all gentleness and only with your best interests at heart.

<soapbox>
Beware! I know more programming languages and environments than I can count and I can say, unequivocably, that there is no easier to develop in environment than Access. Same with maintenance. I highly recommend Access, especially if you don't know what you're doing.

Another approach is to develop/prototype your system in Access and then convert it to another platform. That way, you at least get the fast development time and prototyping abilities that Access just kinda has built in as a template for your other programming environment.

Microsoft has spent billions of dollars plugging features into Access that just work out of the box. There is absolutely no way that you'll ever be able to put as many features into custom written software as they have already built in, as long as you buck the trend of most Access developers and use the built-in functionality.
</soapbox>

I hope this helps you make a decision. If you need help with Access development, we're here to help guide you.

Truly appreciate your advice as I didn't really know the limitations of programming, all these advantages and disadvantages..

Hmm. What does it mean to develop/prototype in Access?

Right now we have a version of the database that is not as normalised as it could be even though it kind of works, and also another version that is nicely normalised but has no forms. (This latter version is the one that he might want to use as a back end.)

 

[georgedwilkinson]

Prototyping is quickly creating a demo or model that actually can become a working system with few tweaks.

Access' power does not become apparent on non-normalized databases. With a fully normalized model, Access' wizards can prototype incredibly quickly, embarassingly quickly. Few other environments can do that. And no OLTP system will work well with a non-normalized model.

I've found that with Access development, most of my time is spent normalizing the database. I spend very little time writing code, and most (not all) of that is to overcome somebody else's model mistakes or to automate external processes.

 

[Call_Me_Sam]

cicak, i agree with george on the use of Access as a development tool.. i begun learning .Net languages thinking we could build custom interfaces for our databases, but when it came to the crunch the things i can do with Access meet the needs to the users, are stable (most of the time) and are quick to develop and deploy..though give me SQLServer anyday as our databases are hitting that lovely 2Gb mark more frequently..we have just too much information...

 

[georgedwilkinson]

And even using SQL Server as the backend, Access is just a massively fast front end development tool. In fact, for any database centric application, I'm not sure that you can prototype as fast with any other development tool. And I'm just way too lazy to do it wrong. If something comes along better/faster/easier, I'll be right there.

 

[Call_Me_Sam]

And even using SQL Server as the backend, Access is just a massively fast front end development tool. In fact, for any database centric application, I'm not sure that you can prototype as fast with any other development tool. And I'm just way too lazy to do it wrong. If something comes along better/faster/easier, I'll be right there.

but then would you agree George, that MS designed their products to work well together, and third party drivers linking to say Oracle would for some reason be 'slower'...

 

[georgedwilkinson]

No, I wouldn't say that. In general I've found that a well designed Oracle application is faster than a well designed SQL Server application. But the difference is insignificant for most projects. You can use Access as a front end for either in most business cases and both will work fine.

But I would be using Oracle drivers to connect to Oracle, not MS drivers.

 

[Call_Me_Sam]

guess this shows my experience of working outside of Access, we do have Oracle here but for Data Warehousing purposes, not for our business as usual stuff.

 

[Cicak]

You guys lost me there.. I guess I haven't the experience to fully follow the discussion! I've a lot to learn about this front-end back-end stuff.

So.. In most cases, use Access?

 

[georgedwilkinson]

Access will suit you very well unless you have a huge data set or a plethora of users (I haven't maxed out at 30+ with a SQL back end).

 

[Cicak]

Ok.
Thanks very much George and Sam!