|
Planker wrote: I am trying to create a table in an Access database
I have verified all of my SQL commands work in SQL Server
Access SQL is NOT EQUAL to SQL Server.
Therefore your test is invalid. Try testing your SQL in the Database you are targeting. That is always the best approach.
Good luck
led mike
|
|
|
|
|
Thanks, I am trying to figure out what the correct commands are, I see examples all over the internet using the SQL create table command on a Access using OLEDB, but everything i try does not work.
modified on Wednesday, October 8, 2008 2:02 PM
|
|
|
|
|
Planker wrote: Thanks, I am trying to figure out what the correct commands are
Sure, but wouldn't something like the documentation[^] be a good place to start?
led mike
|
|
|
|
|
Thanks for pointing me in the right direction, I am making some progress now.
|
|
|
|
|
Planker wrote: I am making some progress now.
Cool ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
led mike
|
|
|
|
|
Hi!
I am currently working on a project, where I have to make an API assembly to our main functionality.
The issue is that i'm in fact making two assemblies one, which is comon and one which intented as the assembly, which should expose the API functions to our customers. If I try to use the API assembly my common assembly is also required for the client program which is using my API assembly in order to compile, even though I have no direct referances to the common assembly are thiere any way that I can get around this so that I do not have to referance the common assembly in by client program ?
Many thanks in advance.
Kind regards
Jakob
|
|
|
|
|
Ummmm, what?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Well I will try to clarify. I have two assemblies, which makes up my api and I will like to keep that way and I only want to expose one of the assemblies to my custormers. So that they in principle only have worry about one of the assemblies and referance only one assembly in there client programs.
I hope this clarifies the problem.
Kind regards
Jakob
|
|
|
|
|
If there are no dependencies between them why not just compile them as two independant dll's?
If there are interdependencies then just compile them to a single dll.
Or have I missed the point entirely?
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Instead of doing two assemblies, make one, and make the classes in the non-public one private within the public one.
Any public object in an assembly will be exposed. See if there's an .Net attribute available that marks a class as not exposed or something like that. If not, you'll have to follow my first suggestion.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Yes you can. Although I would not recommend it you can embed the assembly as a resource in another assembly and then return it from an Assembly Resolve event such as
appDomain.AssemblyResolve += new ResolveEventHandler(OnAssemblyResolve);
In the event call your assembly and ask for the other assembly as a binary file and viola.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
No, but you can have a class inside a class, is that what you mean?
|
|
|
|
|
|
Hi!
I just stumbled over an unexpected behaviour when trying to serialize a derived class using a BinaryFormatter, I guess the best is to show in code:
Animal a = new Animal();
Dog d = new Dog();
Animal dogAsAnimal = d as Animal;
BinaryFormatter bf = new BinaryFormatter();
bf.Serialize(serializationStream, a);
bf.Serialize(serializationStream, dogAsAnimal); I can't really understand why the last line is trying to serialize the object as Dog instead of Animal - is there any way to keep BinaryFormatter from doing this (short of adding a copy constructor to Animal and actually creating a new object)?
Thanks in advance!
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
bf.Serialize(serializationStream, (Animal) d); ?
|
|
|
|
|
It doesn't matter whether I use as or an explicit cast.
In the real code I had a method ToFile(Animal a, string path) and it also showed the effect.
The debugger does show that it's an Animal reference in every case.
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
The derived class also has to be serializable.
I think you'll also find that only protected and public vars will be serialized from the base class, but I'm just guessing at that.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
But that's something I explicitely do not need/want. Of course I could flag Dog as Serializable, too, but then the object is serialized as Dog, not as Animal.
The other side of the line (where the object is supposed to be deserialized) doesn't know about Dogs, it only knows about Animals (i.e. there's only the assembly defining Animal available, not the one defining Dog, so trying to deserialize this object will throw a TypeLoadException).
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
Well, it appears from your code sample as if you really want to serialize the Dog object. I don't understand why you wouldn't want to do that, since you can Deserialize it and cast it back to animal if that's what you really need. Why in the world would the deserialize code not know about the dog object. It looks from here as if your design needs to be re-engineered.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
The simplest explanation for what mav's doing is that animal is owned by a different team and are either unwilling or unable to modify the object to contain additional functionality that is needed in mav's part of the project. For every part of the app except serialization having dog inherit from animal makes a more natural design than having dog have an animal member.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
Well, things tend do become simplified when stripping the context.
I have a system of several client applications and a server that are communicating via remoting. They all have a notion of Animal. Animal has a method public static void ToFile(Animal a, string file) (and the corresponding FromFile()).
For a new client, a Dog class had to be created, but since this class is only used with this client it doesn't make sense to put it into the library defining Animal.
Then the client wanted to serialize the Animal-part of one of the Dog objects using the static Animal.ToFile() method, but the binary formatter threw an exception because Dog wasn't marked as serializable.
The most intuitive method (for me) to solve this problem would be to find a way to tell the BinaryFormatter that what he gets really really is just an Animal, but I don't know how.
Other solutions would be to use aggregation instead of inheritance, but that would require some rewriting of existing code.
Or I could add a copy constuctor to Animal and actally create a new object, but that's not really the idea - I don't want to serialize a copy of a Dog, I only want to serialize the Animal-parts of the Dog...
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
Objects have to have public, empty constructors to be serialization using the built in methods (Don't quote me) and need to have the Serialization attribute as well as the ISerializable interface for binary serialization.
Base classes, in general, can't be serialized if they can't be instantiated.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: Objects have to have public, empty constructors to be serialization using the built in methods
Not true. No constructor is used in deserialization AFAIK.
Ennis Ray Lynch, Jr. wrote: Base classes, in general, can't be serialized if they can't be instantiated.
Huh?
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
For standard XML serializaiton the default constructor needs to be public. For binary serializaiton you need to have the serialization constructor defined.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: For standard XML serializaiton the default constructor needs to be public
What if there's no default constructor?
Ennis Ray Lynch, Jr. wrote: For binary serializaiton you need to have the serialization constructor defined.
Not true. That's only for ISerializable-derived classes.
ISerializable isn't required for binary serialization.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
