Database Development In General (1 Viewer)

Acceesbility

Registered User.
Local time
Today, 02:17
Joined
Jan 4, 2017
Messages
32
:eek:

Is it a good idea to create a database in MSAccess and then convert to an SQL version?

Now that I've been looking about at Database Development in general, I find myself overwhelmed by the options available and wonder now what is the best platform to learn?

Anyway, if anyone might be kind enough to summarise the options available with advantages / disadvantages or throw in a few shortcuts to relevant topics to consider, that would be great.

Any suggestions would be much appreciated.

:D
 

Ranman256

Well-known member
Local time
Today, 05:17
Joined
Apr 9, 2015
Messages
4,337
Yes. All you would do is remove the Access backend, then link in the SQL tables,and rename them to the access names as before.
The change should go un-noticed.
 

sonic8

AWF VIP
Local time
Today, 11:17
Joined
Oct 27, 2015
Messages
998
Yes. All you would do is remove the Access backend, then link in the SQL tables,and rename them to the access names as before.
The change should go un-noticed.
Well, after doing this everything should "work" (sort of).
However, depending on the complexity of the queries in the database the performance of some queries might be abysmal.
Complex queries should be rewritten as Views, Stored Procedures, and/or Function on the SQL Server to benefit from the migration.
I strongly recommend testing any database migrated to a SQL-Server-Backend with a real life volume of data to identify any performance issues, before putting it into production.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 10:17
Joined
Feb 19, 2013
Messages
16,627
I can only think of 5 reasons for using SQL backend (other than 'just because I can')

1. db size over 2Gb
2. higher level of data security
3. large number of users
4. users connecting across WAN
5. IT decreed (i.e. because you must, regardless)

depending on how well the front end is designed, performance is rarely improved. Performance is more affected by reducing network traffic and improving network bandwidth.

Having said that, Sonic's points will go some way to reducing network traffic.

Simplistically, SQL Server uses 4 cores to manage db processes, whilst Access (and SQL server express) uses 1. But SQL server is often doing a lot more than just your app, so it is quite possible that you app will only be allocated effectively say 1/2 a core. All depends on how the db processes are being managed.

By all means use an access backend to develop a proof of concept. But in my opinion, if it has been decided for a new app the back end has to be SQL, then start development using SQL
 

sonic8

AWF VIP
Local time
Today, 11:17
Joined
Oct 27, 2015
Messages
998
1. db size over 2Gb
2. higher level of data security
3. large number of users
4. users connecting across WAN
5. IT decreed (i.e. because you must, regardless)
Good summary list!
If the list is ordered by general importance/significance I would swap item 1. and 2. With 'data security' being more important that all others combined.

And I would add one item to the list:
Much greater capabilities of the (T-)SQL query language of SQL-Server. That applies to the level of individual statements as well as to the 'routine level' of procedures, functions, triggers, et al.
For me personally that would be an explicit item on the list, because I grew a strong dislike for Access' shortcomings in the SQL department. Beyond that, this point is still worth mentioning, because it is (at least partially) the foundation for all other reasons.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 10:17
Joined
Feb 19, 2013
Messages
16,627
list wasn't ordered - just 'if any of these apply, then use sql server'

but agree about data security - although only one aspect - users can't walk off with a copy of the back end, but I've seen plenty of sql based systems where users can export entire lists of data as normal functionality through the (poorly thought out) front end.
 

Acceesbility

Registered User.
Local time
Today, 02:17
Joined
Jan 4, 2017
Messages
32
Hello

I'd like to thank you all for responding to my post.:D

C_J London Wrote:
By all means use an access backend to develop a proof of concept. But in my opinion, if it has been decided for a new app the back end has to be SQL, then start development using SQL

If It's Been Decided SQL - Then Develop in SQL From The Beginning.
Sure, that makes a lot of sense.
(The thought behind my question was if I had an existing Access database, would it be practical to convert to SQL
From what I've read within the responses the answer is yes, as long as the Access Database is of reasonable design.)

In terms of a Professionally Developed Access Database, how would you explain the 2GB limit to the uninformed newbie. I find it difficult to comprehend that limit in a practical sense.

:)

Considerations:


  • Higher level of data security
  • Database size over 2Gb
  • Large number of users
  • Users connecting across WAN
  • IT decreed (i.e. because you must, regardless)
  • Much greater capabilities of the (T-)SQL query language of SQL-Server
Thanks

:D
 
Last edited:

CJ_London

Super Moderator
Staff member
Local time
Today, 10:17
Joined
Feb 19, 2013
Messages
16,627
how would you explain the 2GB limit to the uninformed newbie

take a look at this link to get an idea

http://heresthethingblog.com/2012/05/22/big-gig/

all data takes up space on a drive. see this link for detail for each datatype

https://msdn.microsoft.com/en-us/library/aa263420(v=vs.60).aspx

when you store data, there are other space requirements as well for indexes, object definitions and the like.

A well designed database is less concerned about the space that is required but more concerned about fast operation. Not having indexes saves space, but slows the db down to maybe 1% of an indexed equivalent if there is a very large amount of data. Not repeating data makes it easier to maintain etc. If you don't know about indexing, see this link

https://www.access-programmers.co.uk/forums/showthread.php?t=291268

I have db's well within the 2Gb limit with millions of records - and there will be others here who can tell you the same. I think in all the years I have been developing there has only been a handful of times where space has been an issue.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 04:17
Joined
Feb 28, 2001
Messages
27,209
how would you explain the 2GB limit to the uninformed newbie

When Access first came onto the scene, the only choice was the 32-bit version. What do we mean by that? It derives from something called a "memory model" used by PCs. Last I looked, there were at least five different models having to do with address sizes and ways to establish pointers to entities. (Talking in generalities here, not "entity modeling" concepts.) When you write a program that allows arbitrary internal data structure building, you have to allow for ways to point to those structures at very fine-grained levels. We are talking "address" variables here.

Recordsets are based on tabledefs or querydefs that each contain a fielddef item, which in essence is a descriptor of each field in the record using byte-oriented offsets from the beginning of the record. So once you have established a buffer for a recordset and a record is read into the buffer, the offsets contained in the individual field definitions tell you how to find the data for a given field. The key is that since you can address BYTE variables (Boolean, Byte Integer, and Char data types), you can't "play games" with address pointers without wasting address space, so that means that you are limited to addresses with 32 bits in them.

On any model based on a 32-bit architecture, you can play tricks with addresses, but here is the absolute cold bottom line: 32 bits equals about 4 Gb worth of discrete addresses. So the absolute upper limit for a 32-bit program is to be able to address 4 Gb at a time within the address space it can claim.

The next question that contributes to the answer: I'm going to have code and data structures (representing printed or graphic forms and reports) in memory, and I'm also going to have potentially large data tables in memory. How will Access keep them separate? Answer: By dividing the address space of the program between GUI structures and actual data. The EASIEST way is to take the address of 32 bits and divide it in half. One half goes to the actual MSAccess.EXE program itself and to the forms, reports, macros, modules, and query definitions, and to the table definitions used to get to the tables. The other half goes to the actual tables.

That means 1/2 of your 4 Gb is Access code, VBA code, and GUI-related and print-related stuff, including libraries (.DLL - see "References") and such, or 2 Gb. The other 1/2 of that address space is your data tables and as such, is 2 Gb.

The next obvious question is, how do I differentiate between tables in two different databases? The answer is that memory management hardware allows you to have multiple database segments open at the same time - but you only address the data segments as you need them. Clever (no... downright diabolical) dynamic manipulation of the memory management pointers allows a part of that data space to be used for one BE file and a different part for another BE file. But NOTHING can violate the hardware rule that says the total amount of memory addressed at once by a 32-bit version of Access can never exceed 4 Gb. In essence, Access makes each MDB or ACCDB file a VIRTUAL address space (and you can look up using VBA to open a virtual file; it is instructive and relevant to this discussion). I believe there is a limit of 16 possible database files because there is (probably) a fixed number of virtual file data structures allocated within Access. But this is an educated guess; please count it as such.

Please also note that with the advent of 64-bit Access and the "PtrSafe" declaration, addresses can now be 64 bits long, leading to memory spaces in the Tb range and higher. However, the internal structure of Access, as far as I can tell, still has not fully caught up and, as a native Access BE, still has that size limit. Using SharePoint (I am told), programs CAN use 64-bit addresses and thus can break the size limit. But I am not going out on a limb regarding what SharePoint does for you other than break that size barrier.

In any case, to summarize the answer, the 2 Gb database limit derives from a needed sub-division of the address size used by the largest PC memory model available when Access was first created.
 

Lightwave

Ad astra
Local time
Today, 10:17
Joined
Sep 27, 2004
Messages
1,521
:eek:

Is it a good idea to create a database in MSAccess and then convert to an SQL version?

:D

Echo everyone else - no if your production application is going to have a SQL backend and just develop in SQL Server.

As you get into it you will find that backend choice is usually pretty simple - quite often backend choice comes down to.
SQL Server (Generally because its in situ)
Oracle (Generally because its in situ)
Access (Generally because you can't connect to SQL Server or Oracle)
MySQL (Generally because you are doing web development)

The real complexity comes in when creating the front end. Smooth UIs are incredibly difficult to develop and for first timers they get totally confused at the rate of change in front end options and the much more complicated configuration of front ends (particularly on the web).

Access front ends are the exception they are about as easy as you can get.
 

Users who are viewing this thread

Top Bottom