By Kirk M Sherhart - 7/31/2009
I'm getting the following message during installation of 1.7.0. It fails during the "Searching for SQL Servers" part
Runtime error
Line 269; '' is not a valid integer value
|
By Trent L. Taylor - 8/3/2009
Wow, it that all it gives you? This appears to be coning from the installation package (if I am not mistaken).
There are a couple of things that you may want to try:
1. Manually remove ANY MicroFour StrataFrame XXX.DLL from the GAC (c:\windows\assembly). This should have already been done by the installer, but at times it can be difficult, due to permissions, etc. to forcibly remove them all.
2. Make sure that you run the install with administrative permissions.
3. If the problem persists after the above two, then we will want to make sure that there is not an install cache hanging around. The install creates a temp local cache stored off under the local user or public / default user with a folder in the form of a GUID. Inside of the folder is a full install. If you localte one of these, you can just smoke it (Texan for delete), 
Let me know if this doesn't help.
|
By Kirk M Sherhart - 8/3/2009
Hi Trent
It didn't work. I removed the old DLL's from the GAC and I couldn't find any cache directory. I have Local Admin rights to my machine. (BTW, v1.6.7 installs just fine.) The install process still fails in the same way with the same message.
What next?
|
By Trent L. Taylor - 8/3/2009
Re-download the install and try again. I have had downloads get hosed before and simply re-downloading may work. The build is sound and we have a lot of installs at this point, so let's look at the most simple before we get more complex.
|
By Kirk M Sherhart - 8/3/2009
Still no go. I re-downloaded the install package, but I still get the same message at the same spot.
I reinstalled v1.6.7 and I noticed during the SQL Server discovery process that only my local machine's SQL Server was available. I seem to remember the very first time I installed StrataFrame that I could see many potential SQL Servers on our network, but not any more. Perhaps this gives you a clue.
Thanks!
|
By Trent L. Taylor - 8/3/2009
Sorry, but no clue. I have tested this on some other VMs as well as other live laptops....so I know that the install works. So there is something going on local to your environment. Do you have another machine you can load SF on to see if you have the same issues? That would be a helpful start if possible.
|
By Edhy Rijo - 8/3/2009
Kirk, also try log in your computer with another user account, it could be possible that something may be corrupted or an Antivirus/Firewall may be causing this issue.
|
By Trent L. Taylor - 8/3/2009
Good idea, Edhy. That might help as well.
|
By Kirk M Sherhart - 8/3/2009
Hi Trent
Still trying... Just curious: when you did the install on laptops, were they connected to a network or not? I'd be curious about the result of installing on a disconnected laptop.
I've tried installing v1.7.0 on another machine, complete with a fresh VS2008 install. Still get the same problem. I'm trying to pursue with our Network people why I can't see SQL Servers on our network like I used to.
Thanks for all the help. In case we can't resolve this, is there a "manual" installation option?
|
By Trent L. Taylor - 8/3/2009
Still trying... Just curious: when you did the install on laptops, were they connected to a network or not? I'd be curious about the result of installing on a disconnected laptop.
Yeah, I suppose that they were and the VM sessions were as well, but that should not affect the install overall. If you cannot see the SQL servers, then they are most likely not running the browser service (as that is what exposes them).
|
By Kirk M Sherhart - 8/3/2009
Hi Trent
I agree that being disconnected "shouldn't" affect the installation. But something must have changed from v1.6.7 to v1.7.0 that prevents the installation.
Still working on this end... I used to be able to see many dozen installation of SQL Server here, but now I see none! I can't believe everyone simultaneously stopped using the Browser service here.
Again... If we can't find a solution to this installation problem, is there a "manual" install option?
|
By Trent L. Taylor - 8/3/2009
Well, the code that actually is looking for the SQL Servers is not something that we wrote, but rather the installer pulls back. In regards to a manual installation, if you type in the SQL Server and click next, is this where you get the error?
Worst case, check the "Skip deploy structures" option and then after the install you can open up the DDT and manually deploy the StrataFrame.pkg file. That would be the only "manual" way to do this. It sounds like the failure is happening on the search or authentication. I need to know which because the search is not us and the authentication is.
|
By Kirk M Sherhart - 8/3/2009
The error pops up almost immediately after the "Status: Searching, please wait..." in the "Searching for SQL Servers" panel. No other input is requested. Once OK is clicked, the installation process is blown away.
|
By Trent L. Taylor - 8/3/2009
OK, so this is actually coming from the MSI then, not our assembly. This isn't making any logical sense as there is no difference between 1.7 and 1.67 in this regard. In fact, this goes back much further than that. So that iis what is confusing me as you have said that 1.6.7 is working and the 1.7 is not.Do you have a copy of SQL Server loaded on your local machine? Do you have more than one version of SQL native client loaded?
|
By Kirk M Sherhart - 8/4/2009
Hi Trent
I only have the copy of SQL Server that came with VS2008 (I'm normally an Oracle user.) Using SQL Server Configuration Manager shows only my local SQL Server (and Browser Services) running. The available client protocols are Shared Memory, TCP/IP and Named Pipes.
When I install v1.6.7, the only option for a SQL Server given is for my local machine. None of the network servers are visible (which is why I'm still pursuing the issue with our IT group.) I get the same thing when trying to finding databases via VS2008's Tools/Connect to Database... dialog.
I know it's strange!
|
By Jerry Carter - 9/28/2009
I'm having the same problem. I'm running a fresh install of Windows 7 with VS2008, SQL 2008 and an instance of SQL Express. This thread is a few months old. Any new ideas?
|
By Jerry Carter - 9/28/2009
I do not have v1.6.7 but I was able to install v1.6.6. I should also add that the version I'm getting the error with is v1.7.2.
|
By Trent L. Taylor - 9/29/2009
Well, for whatever this is worth, this is not reproducable which tends to mean that there is an environmental issue. Also, it is important to note that this logic has not changed in a very long time. So I would ensure that you have TCP/IP turned on and setup for SQL Server to make sure that it can be reached via sockets. If SQL Server is on the same machine as VS then this should not matter. But the one difference that you may be experiencing is that support for SQL Server 2008 and SMO 10 whereas 1.6.6 did not have this support.
So the first thing that I would do is turn on TCP/IP support for SQL Server through the configuration manager, restart the SQL services, and then make sure that you can connect to the localhost.
|
By Jerry Carter - 10/10/2009
I've tried just about everything that I can think of. TCP was already enabled. I've completely patched VS2008 and SQL Server 2008. I do not have much else loaded on my laptop. It's a pretty fresh install. I installed Windows 7 when it became available. I guess the next step is to completely uninstall and reinstall. What do you think?
|
By Trent L. Taylor - 10/12/2009
I believe that the issue may be Windows 7. I will load a VM and see if that is the case.
|
By Michael Keller - 2/24/2010
Had the same trouble. Error 269 when searching for SQL servers. Setup: new VM of Win7 prof. with VS2008 sp1, SQL 2005 express. Everything functioned except the install of StrataFrame. Machine name assigned during the install of Win7 was WIN-7OA2349UYYYAO. Changed the name to WIN7VM and the problems went away for the Strataframe install. If I had to guess, I would blame the dash.......
Mike
|
By Dustin Taylor - 2/25/2010
Definately odd! Thanks for the heads up on the machine name. I've run into the same problem on an install of our medical application, but as Trent has mentioned, we've never been able to reproduce it reliably. I'll have to do some investigation to see if the machine name suspicion pans out with my experience with the issue. We use InstallAware for all of our installs (which we have otherwise had good luck with), so thier in-built SQL detection isn't something we have direct control over. We did add an option to our medical app to skip the SQL Detection to get around the issue when it came up for me (I wasn't smart enough to check the machine name  ). I'll talk to Trent and see if we can get that put into the StrataFrame install for the next build. Worse case, that will give you a work around in case we can't pin down the sourc eof the problem and it crops up again. Thanks again!
|
By Kirk M Sherhart - 2/25/2010
That's a very interesting find! All of the computers here have names in the form of "ABC1234-XYZ5678", which explains why the install procedures can't "see" them.
Looking forward to the option to skip SQL detection.
|
By Greg McGuffey - 2/26/2010
Hmmm...I've always installed SF to a SQL server with a dash in the machine name. Never had a problem. Was SQL Server 2k though on Windows Server 2003, if that makes any difference.
|
By Edhy Rijo - 2/26/2010
I think it may have to do with the length of the computer name used. Even though Windows let you use more than 15 characters I believe it will recognized up to 9 or 15 in some OSs, since Michael changed the computer name to "WIN7VM" and the problem was gone, means that it definitely have something to do with the computer name.
Probably the function used by SF or IA installation has a limitation on the computer name.
|
By Trent L. Taylor - 3/1/2010
We are investigating this on the IA side. We may change the way that this search takes place as we are, at present, allowing IA to do the search. We can turn the automatic search off altogether and it will never show the error, but it also requires that you know the SQL Server name...which seems like a simple thing, but we have a number of developers who are not only new to .NET, but new to SQL Server many times as well and this step is more difficult.
Also, I have seen this when people are loading on a VMWare environment as well, just FYI.
|
By Greg McGuffey - 3/1/2010
Edhy Rijo (02/26/2010)
I think it may have to do with the length of the computer name used. Even though Windows let you use more than 15 characters I believe it will recognized up to 9 or 15 in some OSs...
All server names I've used have been less than 15 characters, though almost all had a dash.
|
By Alex Luyando - 3/18/2010
Add me to the list of users having this problem. My attempted install is on a new Windows XP Pro workstation; had no problem installing on the old workstation. The new workstation's name is SBK012DD62D1EMG, while the old one (which has no problem installing 1.7.0.6) is sbk012cs56d1... so perhaps length is indeed the issue.
By the way, re-reading Michael's post I think he's saying his workstation/VM's name is XXXXXX-YYYYY, not the SQL Server he's looking to connect to.
Due to corporate naming conventions will be difficult to get a name change to the workstation... Any predictions Trent on a new install that will resolve this?
TIA
|
By Trent L. Taylor - 3/18/2010
I will be posting a beta very shortly that will resolve this particular issue. For now we will just not scan the network for SQL Servers, which is what is causing the issue. I am waiting for an answer from our installation tool vendor on the root of the issue.
|
By Alex Luyando - 3/18/2010
Trent L. Taylor (03/18/2010)
I will be posting a beta very shortly that will resolve this particular issue. For now we will just not scan the network for SQL Servers, which is what is causing the issue. I am waiting for an answer from our installation tool vendor on the root of the issue.
Great. Just to be clear, in our case at least it's not the name of the SQL Servers (they've not changed); it's the name on the workstation on which StrataFrame's being installed. So long as the beta will solve the problem, cool! 
|
By Alex Luyando - 3/18/2010
FWIW in case it helps someone else - Was able to rename the workstation (dropped 3 characters to bring the total character count for the name to 3) and the install is working (i.e., it's gotten beyond the error point).
|
By dgsoft - 7/15/2010
Hmmm...today I have the same problem when I try to install StrataFrame on home Windows 7 machine.
What the solution for this? Rename my machine computer name? How many characters it must be? Why installer not fixed if its well known problem?
|
By Ivan George Borges - 7/15/2010
It looks like you are on version 1.7.0.6Have you tried the 1.7.0.7?
|
By dgsoft - 7/15/2010
Thank you Ivan,
Yes, with new Installation Wizard it works.
|
By Ivan George Borges - 7/16/2010
Glad it worked!
|