Re: Attachment #1

I'm going to try SF again - so I ran the installer for the latest version 2/15/07.

Got the attached error.

What does it mean?

What do I do next?

Re: Attachment #2

I clicked on Business Binding Source and got the attached error?

???

Howdy, Dan,

It looks like your StrataFrameSample database didn't get deployed like it should have during the install.  You should have a .log file in your C:\Program Files\Common Files\MicroFour\StrataFrame folder that contains information on the deployment process.  If you could post that out here for me, it might give us a clue as to what the error was that occurred while trying to deploy the data.

Thanks

I removed and retried the install today.



The good new is Yes, there is a log file.

The bad new is that its length is 0 bytes.



same story from yesterday.

More than likely you have installed StrataFrame to this SQL Server before, but dismounted the StrataFrame database rather than delete the SF database.  When this happens, the SQL MDF file is left on disk so when the database is attempted to be created, it fails because it cannot create the file group.

The error in the sample is because you have not properly installed the databases.  If the database is not there....then you will get an error.

The issue is on the side of SQL Server.  Either the MDF, permissions, etc.  But all in all the database cannot be created due to an issue on the side of SQL Server.

After talking to you it was a simple matter to resolve the problem. The old data files were:

1 - not reattached when I upgraded to SQL 2005

2 - After reattaching them, the install still failed suggesting that the old format (or something) is not compatible with your latest release.



After delete the old file, the install finished normally.



It would be nice if the installer did some tests and/or provided the option to kill the old databases and make a new set. I wasted several hours screwing around with this because of the lack of a useful error message or a more fault tolerant app.



Thank you for your help.

Since doing the install I get the following error:



Error HRESULT E_FAIL has been returned from a call to a COM component



any time I try to paste dataGridView controls onto a form or try to drag a data source onto a form or try to rename a bindingSource.



Any idea what got corrupted?



Thanks

See Attached.



Uninstalling SF apparently does an incomplete job of cleaning VS2005.

This is not a safe thing to do outside of the local machine or programatically.  This is a message that comes back from SQL Server when trying to mount a database or create a file group using SMO. 

This file is removed with the installation...you do not have a clean installation.

Well, first of all, if the installation had produced as fully functional VS2005, I wouldn't have needed to uninstall it again.



Secondly, the uninstall left all of the ToolBox items as well as the addin.



Thirdly, as far as not being able to tell if the the databases exist and are mounted, The following code, as you know, will tell you if the database is mounted or not (by throwing an exceptions). If it is mounted you can get the file paths. I it's not mounted, you can do a file exists on the path that you intend to copy the file to and -

a) decide whether to skip the copy or

b) ask the use if they would like to delete the old files (which by this time you know are not mounted.



Now I don't know what capabilities you installer builder offers but I know I could do something like the code below with InstallShield. It's not fancy but you can get the idea. Obviously this is sort of pseudo code and there's no point in working it out so that it's clean and tight but it demonstrates that it is possible to anticipate the common scenarios that might prevent a successful installation and deal with them.



I'm sure that you know all of this and what I've included here probably seems kind of amateurish to you but I have made numerous good-faith efforts to install and use StrataFrame and, so far, i have never gotten more that a week into an attempt before I have been stopped in my tracks by some kind of bug or quirk or my inability to read your mind. Each time this has happened I have been forced to use other techniques because I couldn't wait long enough for support and/or a patch.



I think you guys have a good concept and most people must be using it without these kinds of troubles. I would like to be one of them.



All I can in my defense is that if got 40 years experience programming and I've got commercial software deployed to thousands of users. From time to time I have run up against a situation where my stuff would not behave as expected on someone's machine. In each instance, I have tackled the problem and worked it through to the point where the issue was identified and fixed. It's never easy and not always quick.



Anyway I'll be back working with CSLA while I await your reply.

Thanks,

Dan

--------------------------------------------------------

cm.CommandText = "use StrataFrameSample";

cm.CommandType = CommandType.Text;

try

{

   int i = cm.ExecuteNonQuery();

   cm.CommandText = "use StrataFrameSample; select * from sys.database_files;";

   SqlDataReader reader = cm.ExecuteReader();

   while (reader.Read())

   {

      string filename = reader.GetString(6);

      Console.WriteLine(filename + " exists " + File.Exists(filename).ToString());

   }

return;

}

catch (Exception ex)

{

   Console.WriteLine(ex.Message);

if (AttachDbAtDefaultLocation())

{

// files are where you expect them and are mounted

}

else

{

// They're not where you expect them

//so there is no problem putting another set in the default location

CopyNewFilesIfNeeded();

// now do the attach

//etc...

}

}

//etc....



bool AttachDbAtDefaultLocation()

{

   using (SqlCommand cm = cn.CreateCommand())

   {

      try

      {

         cm.CommandText = "EXEC sp_attach_db @dbname = N'StrataFrame', " +

         "@filename1 = N'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\StrataFrame.mdf', " +

         "@filename2 = N'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\StrataFrame.ldf' ;";

         cm.CommandType = CommandType.StoredProcedure;

         cm.ExecuteNonQuery(();

         return true;

      }

      catch (Exception ex)

      {

         return false;

      }

   }

}



void CopyNewFilesIfNeeded(bool DoDelete)

{

   string[] filesToCopy = new string[]{"c:\path\a.mdf", "c:\path\a.ldf"};

   foreach (string file in filesToCopy)

   {

       if (File.Exists(file) && DoCelete)

       {

            File.Detete(file);

       }

       else

       {

            DoCopy();

       }

   }

}

Daniel,

It is not my desire to sit here and spar with you and I appreciate your attempt to try to come up with some code, but there are some inherent issues with your code that will not work in a commercial environment.

When creating commercial developer tools, which I am sure that you can respect and understand, you have to take more into account than the local computer or simply copying a file. Your code makes some assumptions in regards to the machine permissions such as full administrative rights.  Additionally, the file group name may be using the $DbName$ tag which then creates a moving target and even further complicates the situation.  Many times developers are installing to remote SQL Server environments with very limited credentials.  This means that these developers may not have any Windows security rights whatsoever.  This is why the installation environment MUST remain and respect the SMO and permissions granted. 

 

And we have also made many attempts, including numerous screen sharing sessions to get you going just to learn in most cases that it was simply configuration and installation issues outside of the scope of StrataFrame.  But we too, in good-faith, are interested in taking care of our customers and helped you even though in these circumstances the issues were not related to StrataFrame.

If there is ever a bug that prevents any of our users from moving forward or if there is not a work around, we do our very best to stop and take care of our customers immediately.  We also are not clairvoyant and if we are not aware of a problem we cannot address it.

As always we are dedicated to providing excellent support and taking care of our customers.  I am not sure why you have always seemed to struggle while others do not but this is a moot point as we are dedicated to helping our customers regardless of their circumstances.  The issue that you have mentioned here is again, not related to StrataFrame but rather an issue with you dismounting the StrataFrame database, upgrading from SQL Server 2000 to 2005 and then coming back to later install StrataFrame with other residue left on your machine which caused the problem. 

I appreciate your experience and we always welcome input from all of our developers regardless of their experience.  But in this case I do not think that your experience is the issue but rather a misunderstanding of how SQL Server and SMO work.  Again, we have told you how to work around the issue that you encountered.

I respect your decision and wish you the best of luck.