So obviously you are trying to follow the vast plethora of what i call an over-experienced deployable product - aka SharePoint Server.
As its deployment and administration best practices traveled through time with multiple puddle of sh#t situations to getting ourselves up and learning something new in every version, when it first started in 2003 with WSS 2.0 to a wonder of a product that is 2013 now.
One of the biggest lesson learnt all these years in my experience with multiple clients and deployment was missing out the importance of SQL aliases and the impact it has on migration and custom code in your farm.
So you are a good implementer and like a good implementer would do, you are configuring SQL Aliases for your instance (default or named) before u can run that "Configuration wizard" of yours and see your baby finally come to life. But like many road blocks in planning and designing phase, you get one more when your wizard fails and it turns out it cannot see your configuration database server.
there can be three permutation and combination of situation here.
1. Either your SQL Server management studio 2012 would fail with
2. Or your SharePoint Configuration wizard fails with:
3. Or both.
The core of the problem here is that SQL core database services, though being a 64-bit service. Its client aka Management studio is not, but your SharePoint 2013 is!!
So lesson learnt is to create both 32-bit and 64-bit aliases to avoid confusions
As its deployment and administration best practices traveled through time with multiple puddle of sh#t situations to getting ourselves up and learning something new in every version, when it first started in 2003 with WSS 2.0 to a wonder of a product that is 2013 now.
One of the biggest lesson learnt all these years in my experience with multiple clients and deployment was missing out the importance of SQL aliases and the impact it has on migration and custom code in your farm.
So you are a good implementer and like a good implementer would do, you are configuring SQL Aliases for your instance (default or named) before u can run that "Configuration wizard" of yours and see your baby finally come to life. But like many road blocks in planning and designing phase, you get one more when your wizard fails and it turns out it cannot see your configuration database server.
there can be three permutation and combination of situation here.
1. Either your SQL Server management studio 2012 would fail with
2. Or your SharePoint Configuration wizard fails with:
3. Or both.
The core of the problem here is that SQL core database services, though being a 64-bit service. Its client aka Management studio is not, but your SharePoint 2013 is!!
So lesson learnt is to create both 32-bit and 64-bit aliases to avoid confusions